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Information  management  is  critical  to  the  success  of  a  construction  project. 
Because  of  the  fragmentation  of  the  construction  industry  and  the  diversity  of 
construction  projects,  information  sharing  and  collaboration  are  important  measures  to 
achieve  successful  project  information  management.  As  Internet  based  technology,  such 
as  the  WWW  (World  Wide  Web),  e-mail,  e-commerce,  e-bid  and  e-Builder™,  becomes 
ubiquitous,  many  practitioners  in  the  construction  industry  believe  that  the  Internet  is  the 
way  to  go  for  managing  and  disseminating  construction  information. 

Currently  Web-based  applications  have  greatly  relieved  problems  caused  by 
geographical  fragmentation;  however  these  applications  are  not  designed  to  deal  with 
problems  caused  by  functional  fragmentation.  Consequently,  documents  prepared  using  a 
third-party  software  tool  cannot  be  directly  used  to  retrieve  related  information  in  the 
viewer's  local  system. 
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This  research  treats  a  document  as  a  "malleable  frame"  that  can  be  adjusted 
according  to  user's  needs  and  shows  that  a  "malleable  frame"  system  is  more  efficient  in 
terms  of  processing  construction  documents  than  a  standard  system. 

The  research  shows  that  a  "malleable  frame"  system  is  technically  feasible.  The 
key  is  to  have  a  neutral  data  format.  Currently  XML  (eXtended  Markup  Language) 
related  technology  can  be  used  to  build  such  a  neutral  data  format.  In  addition,  many 
kinds  of  implementation  tools,  such  as  Java,  DHTML  (Dynamic  Hypertext  Markup 
Language)  and  COM  (Component  Object  Model),  are  now  available.  It  is  inconclusive  as 
to  whether  using  the  "malleable  frame"  system  is  more  efficient  than  using  the  standard 
system.  If  document  processing  does  not  require  local  information  or  the  required 
information  is  not  available  locally,  the  "malleable  frame"  system  does  not  perform 
better  than  the  standard  system  does.  Nevertheless,  if  local  information  required  by 
document  processing  is  available,  the  "malleable  frame"  system  performs  at  least  as  good 
as  the  standard  system  does. 
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CHAPTER  1 
RESEARCH  OVERVIEW 

1.1  Research  Objectives 

The  goal  of  this  research  is  to  study  the  feasibility  of  developing  a  "malleable 
frame"  system  by  using  available  computer  technologies  and  to  propose  methodologies 
for  developing  the  "malleable  frame"  system.  Also,  the  relationship  between  the 
malleability  of  a  system  and  the  efficiency  of  processing  a  document  needs  to  be  studied 
to  determine  whether  the  malleability  provided  by  the  "malleable  frame"  system  is 
superior  to  a  system  without  malleability. 

To  achieve  the  goal,  a  series  of  objectives  has  to  be  achieved.  These  objectives 
include: 

1.  Identifying  new  Web  technologies  that  support  the  idea  of  a  "malleable  frame." 

2.  Identifying  methods  for  developing  the  "malleable  frame." 

3.  Applying  the  identified  method  to  develop  a  "malleable  frame"  based  on  a  sample 
construction  document  (a  use  case). 

4.  Identifying  methods  for  developing  the  "malleable  frame"  system. 

5.  Applying  the  identified  method  to  develop  the  "malleable  frame"  system  based  on  the 
"malleable  frame"  developed. 

6.  Testing  the  idea  of  malleability. 
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1 .2  Research  Hypothesis 

There  are  many  features  that  a  "malleable  frame"  can  provide,  while  a  standard 
system  cannot.  Those  features  include  allowing  a  user  to  customize  document 
presentation  and  automatically  retrieve  related  local  information.  This  research  is  focused 
on  the  second  feature.  It  is  this  feature  that  makes  a  "malleable  frame"  system  different 
from  a  standard  system  in  that  a  standard  system  usually  puts  a  received  document  and 
related  local  information  in  separate  windows  while  a  "malleable  frame"  system  can  put 
local  information  right  beside  a  related  information  object  of  the  document.  Therefore, 
the  hypothesis  of  this  research  is  that  (Hq):  if  we  allow  a  document  and  related  local 
information  be  put  together  (in  the  same  window),  the  improvement  in  terms  of  time  for 
completing  a  stage  transition  will  be  significant.  If  |a.„  and     are  population  means  of 
time  for  completing  stage  transition  for  the  "malleable  frame"  system  and  the  standard 
system  respectively,  this  hypothesis  can  be  represented  by  a  null  hypothesis  (Hg)  and  an 
alternative  hypothesis  (HJ. 

Ha:  Ms  -  Mm  >  0 

Ho  states  "there  is  no  difference  between  the  'malleable  frame'  system  and  the 
standard  system  in  terms  of  time  for  completing  a  stage  transition."  H^  states  "the 
'malleable  frame'  system  is  better  than  the  standard  system  in  terms  of  time  for 
completing  a  stage  transition." 

Construction  document  processing  involves  a  series  of  steps.  For  example,  a 
complete  change  order  process  involves  the  step  from  a  Request  for  Change  Order 
Proposal  to  a  Change  Order  Proposal.  A  stage  transition  is  one  of  those  steps. 
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1.3  Research  Scope 

Theoretically  a  "malleable  frame"  system  can  be  used  by  any  construction 
professional  to  deal  with  any  kind  of  construction  document  in  any  kind  of  construction 
project.  In  order  to  narrow  the  scope  of  this  research,  the  research  scope  will  be  defined  in 
terms  of  intended  users,  the  type  of  construction  documents,  and  local  information 
considered  for  test  cases. 

1.3.1  Intended  Users 

Different  project  professionals  may  have  different  project  information  needs.  The 
perspectives  of  different  users  towards  the  same  set  of  information  may  be  different  too. 
This  research  is  focused  only  on  the  needs  of  construction  site  managers  and  site 
engineers  when  dealing  with  a  certain  construction  document.  Since  the  mechanism  of 
how  to  adjust  perspectives  according  to  a  user  is  similar,  the  mechanism  used  in  this 
study  can  be  applied  to  build  systems  for  other  project  participants. 

This  research  will  not  try  to  predict  the  user's  information  needs  when  dealing 
with  a  certain  document.  Instead,  this  research  will  assume  that  a  user  may  need  certain 
types  of  information  for  dealing  with  a  given  construction  document. 

1.3.2  Type  of  Construction  Documents  to  Be  Studied 

Roughly,  construction  documentation  can  be  divided  into  three  phases,  pre- 
construction,  construction  and  post-construction  (Mincks,  &  Johnston,  1998).  This 
research  focuses  on  documents  such  as  change  orders,  shop  drawings  and  RFIs  during  the 
construction  phase  in  which  new  information  is  generated  and  recorded  for  project 
control  and  administration.  Actually,  this  research  will  use  the  Request  for  Change  Order 
Proposals  (RCOP)  as  a  test  document  to  develop  the  "malleable  frame"  system.  This  does 
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not  mean  that  the  methodology  developed  based  on  the  Request  for  Change  Order 
Proposals  cannot  apply  to  other  documents.  The  Request  for  Change  Order  Proposals 
were  selected  only  because  they  are  common  cases  that  project  managers  and  site 
engineers  encounter  very  often.  The  Request  for  Change  Order  Proposals  suit  the 
problem  that  this  research  describes  very  well,  because  the  Request  for  Change  Order 
Proposals  often  refer  to  certain  building  components  or  construction  activities  and  users 
information  from  many  sources. 

The  whole  process  of  dealing  with  construction  change  orders  involves  many 
steps.  It  will  be  redundant  to  study  all  steps  of  the  whole  process.  Since  this  research  uses 
the  Request  for  Change  Order  Proposals  for  the  development  of  a  "malleable  frame" 
system,  naturally  one  step  of  the  whole  process  is  selected.  Accordingly,  a  stage  transition 
between  the  RCOP  (Request  for  Change  Order  Proposal)  and  the  COP  (Change  Order 
Proposal),  will  be  studied. 

1.3.3  Local  Information  Considered  for  Test  Cases 

For  a  project  manager  or  a  site  engineer  to  properly  process  a  Request  for  Change 
Order  Proposal,  he/she  may  need  many  different  types  of  information  that  can  be  found  in 
schedules,  budgets,  specifications,  drawings,  estimates  and  so  on.  In  this  research,  only 
schedule  information  will  be  considered. 

1.4  Research  Significance 

Traditionally,  construction  information  sharing  and  the  document  production  are 
tied  together  (Abou-Zeid,  Russell,  Hanna,  &  Park  1995,  Finch,  Flanagan,  &  March, 
1996).  Such  approaches  limit  the  participant's  ability  to  interact  with  the  information 
source  and  thus  also  limit  the  possibility  of  improving  information  sharing.  This  research 
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offers  a  profound  change  in  the  way  that  project  participants  share  information.  It 
essentially  cuts  the  link  between  data  and  information  presentation.  The  new  approach 
allows  a  user  centered  approach  in  which  users  can  tailor  the  information,  rather  than  just 
passively  use  the  information  whose  content  and  format  are  out  of  their  control. 

This  research  treats  construction  documents  as  media  rather  than  end  products. 
Usually,  documents  represent  the  end  of  a  document  production  process.  Other  processes 
are  treated  separately.  If  other  processes  need  information,  normally  another 
interpretation  process,  either  by  man  or  by  machine,  is  necessary.  This  interpretation  is  a 
waste  (Porter,  1980,  Betts,  1995,  Turk,  1997).  In  this  research,  documents  are  treated  as 
vehicles  of  extendible  objects,  which  can  quickly  integrate  with  other  objects  in  an 
appropriate  way  and  directly  support  other  processes  without  any  intermediate  processes. 

1.5  Research  Methodology 

Many  computer-related  studies  find  that  it  is  very  difficult  to  quantify  the 
performance  or  results  of  information  technology  (IT)  because  of  two  reasons  (Li,  1996). 
First  IT  usually  adds  value  to  other  activities  rather  than  delivering  benefits  directly. 
Second  IT  often  gradually  accrues  to  a  construction  organization  as  a  whole  and  is  not 
always  visible  as  improvements  in  a  short  term.  This  makes  it  very  difficult  for 
quantitative  hypothesis  testing  of  academic  research  studies.  In  fact  some  even  argue  that 
since  there  are  so  many  methods  to  develop  computer-based  applications  and  there  are 
already  so  many  computer  tools  out  there,  it  really  depends  on  users  to  decide  if  a  new 
approach  is  better  than  the  others  and  proper  to  them.  Such  arguments  indicate  that  it  will 
be  enough  for  a  computer  application  research  study  to  just  present  a  technically  feasible 
solution.  However,  there  is  another  completely  different  view  emphasizing  the 
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importance  of  classic  scientific  research  methodology  even  for  the  computer  application 
research  (Harriss,  1998,  Wing,  Raftery,  &  Walker,  1998).  For  this  research,  a 
compromise  is  made,  which  means  that  this  research  will  develop  a  prototype  system  to 
show  the  technical  feasibility  and  also  develop  a  test  system  to  test  the  hypothesis. 

The  research  methodology  employed  in  this  dissertation  consists  of  several  major 
phases  including  literature  review,  development  of  a  "malleable  frame,"  the  "malleable 
frame"  system  design  and  implementation,  system  testing,  and  conclusions  and 
recommendations.  Figure  1.1  is  a  flowchart  illustrating  the  methodology  of  this  research. 
The  phases  are  briefly  discussed  below. 
1.5.1  Literature  Review 

This  phase  of  the  research  is  mainly  focused  on  gathering  information  generated 
by  previous  studies  in  order  to  identify  new  Web  technologies  that  support  the  idea  of  a 
"malleable  frame",  identify  methods  for  developing  a  "malleable  frame"  and  identify 
methods  for  developing  "malleable  frame"  systems.  In  addition,  other  related  subjects  are 
also  looked  into.  Following  is  a  list  of  areas  that  the  literature  review  covers 

•  Construction  information  and  information  management 

•  Current  computer  applications  in  construction  practice 

•  Computer  mediated  communication  and  computer  supported  collaborative  work 

•  Construction  documentation 

•  Web-based  systems 

•  SGML  and  XML 

•  Hypermedia  Design 

•  Statistical  Analysis 
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It  needs  to  be  pointed  out  that  this  dissertation  puts  the  results  of  the  hterature 
study  in  related  chapters  and  sections  rather  in  one  chapter. 

1.5.2  Development  of  "Malleable  Frame" 

In  the  technical  sense,  a  "malleable  frame"  is  equivalent  to  a  document  type 
definition  (DTD)  or  document  schema.  The  DTD  defines  the  structure  of  a  document,  and 
what  and  how  information  should  be  included  in  the  document.  Such  a  DTD  is  a  generic 
document  template  from  which  document  instances  can  be  generated.  Therefore, 
developing  a  DTD  for  a  Request  for  Change  Order  Proposal  is  the  very  first  step  of  this 
research.  Major  steps  of  this  phase  include 

•  Define  the  goal  for  developing  a  DTD 

•  Analyze  document  needs 

•  Design  document  type  requirements 

•  Complete  the  design  of  a  DTD 

1.5.3  "Malleable  Frame"  System  Design 

During  this  phase,  focus  is  given  to  the  architecture  of  the  "malleable  frame" 
system.  Major  activities  involved  in  this  phase  include 

•  Identify  major  hypermedia  development  methodologies  and  tools 

•  Define  requirements  of  a  hypermedia  system  to  be  developed 

•  Define  the  overall  architecture  of  the  "malleable  fi-ame"  system 

1.5.4  System  Implementation 

A  prototype  "malleable  frame"  system  is  implemented  during  this  phase.  The 
system  shows  how  current  Web  technologies  can  be  used  to  build  such  a  "malleable 
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frame"  system.  The  major  tasks  of  this  phase  are  to  implement  the  system  by  using  the 
Java  programming  language. 
1.5.5  Hypothesis  Testing 

In  this  phase,  focus  is  given  to  prove  the  hypothesis  stated  previously.  Tw^o  types 
of  test  systems,  a  standard  test  system  and  a  "malleable  frame"  system  are  built  in  order 
to  test  the  hypothesis.  It  should  be  noticed  here  that  it  is  very  difficult  to  test  the 
"malleable  frame"  itself  Rather  tests  will  be  about  one  of  the  effects  of  malleability.  The 
tests  are  to  find  the  time  difference  between  the  two  systems,  the  standard  system  (SS) 
and  the  "malleable  frame"  system  (MFS).  For  the  testing  purpose,  schedule  information 
will  be  used.  In  the  standard  system,  users  need  to  synthesize  information  to  find  out  what 
decision  to  make.  In  the  "malleable  frame"  system,  related  local  information  is  put  in  the 
same  window  with  the  Request  for  Change  Order  Proposal  therefore  users  do  not  need  to 
find  and  synthesize  information.  For  both  systems,  a  built-in  timer  is  used  to  keep  track  of 
time.  Please  refer  to  the  chapter,  "Hypothesis  Testing,"  for  details.  The  main  steps  of  this 
phase  are 

•  Define  test  plans 

•  Select  test  cases 

•  Set  up  test  systems 

•  Define  sample  and  sample  size 

•  Collect  data  and  information 

•  Statistical  analysis 
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Fi  gure  1.1  A  flowchart  illustrating  research  process 


CHAPTER  2 
LITERATURE  REVIEW 


2.1  Fragmentation  of  the  Construction  Industry 

Fragmentation  is  one  of  the  distinct  characteristics  of  the  construction  industry 
(Howard,  Levitt,  Paulson,  Pohl,  &  Tatum,  1989).  According  to  Porter,  any  production 
process  can  be  viewed  as  a  value  chain.  Each  time  a  product  is  worked  on  in  some  way  or 
another,  not  only  are  resources  consumed  in  that  operation  but  also  value  is  added  to  the 
product  (Porter,  1980).  "These  processes  include  not  only  the  direct  processes  which 
cause  a  physical  alteration  of  the  product  but  also  such  processes  as  moving  the  product 
from  one  place  to  another  "(O'Brien,  1993,  p.  446).  To  be  as  efficient  and  effective  as 
possible,  intermediary  processes  that  do  not  add  value  to  the  entire  process,  such  as 
moving  the  product  should  be  reduced  to  the  minimum  level. 

However,  the  value  chain  of  a  construction  process  is  fragmented  by  at  least  two 
factors  in  general,  geographic  fragmentation  and  functional  fragmentation  (O'Brien,  & 
Al-Soufi,  1993).  The  geographic  fragmentation  is  caused  by  the  fact  that  most  of  the 
construction  projects  are  based  on  temporary  collaborations  of  owners,  architects, 
contractors,  subcontractors  and  suppliers.  In  addition  the  locations  of  the  projects  and  the 
locations  of  these  partners  are  usually  geographically  different,  sometimes  thousands  of 
miles  apart.  The  functional  fragmentation  can  be  noticed  when  project  partners  take 
different  roles  throughout  the  entire  construction  process.  For  instance,  architects, 
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engineers,  contractors,  subcontractors,  suppliers  and  so  on  may  join  the  team  at  different 
stages  of  a  construction  process.  Even  within  a  construction  company,  the  functional 
fragmentation  exists  because  of  different  roles  of  schedulers,  estimators,  superintendents 
and  project  managers.  It  is  thus  obvious  that  fragmentation  permeates  every  aspect  of  the 
construction  industry  and  segments  an  entire  construction  process,  construction 
operations  and  management,  and  project  partners  into  different  phases,  various  functional 
and  management  groups,  and  different  professional  roles  (O'Brien,  &  Al-Soufi,  1993). 
Therefore,  some  intermediary  processes  such  as  effective  and  efficient  communication 
between  project  partners  are  necessary  and  essential  for  the  success  of  a  construction 
project  (Brandon,  &  Betts,  1995). 

One  of  the  main  purposes  of  communication  between  construction  partners  is  to 
share  information.  However,  information  sharing  in  the  project  construction  context  is  a 
necessary  evil.  On  the  one  hand  fragmentation  requires  information  sharing.  On  the  other 
hand  fragmentation  itself  is  the  major  obstacle  for  information  sharing.  Research  has 
already  shown  that,  in  the  construction  industry,  data  provided  by  one  value-adding 
process  is  rarely  in  a  format  suitable  for  subsequent  downstream  processes  (Ndekurgi,  & 
McCaffer,  1988,  Scott,  1995).  This  can  be  viewed  as  data  fragmentation  in  general.  A 
classic  example  of  such  problems  is  the  WBS  (Work  Breakdown  System)  for  scheduling 
and  the  CBS  (Cost  Breakdown  System)  for  estimating.  Because  of  different  levels  of 
details,  the  two  systems  cannot  communicate  with  each  other  without  some  intermediary 
processes  (Abudayyeh,  &  Rasdorf,  1991).  Generally,  data  fragmentation  is  a  derivative 
of  geographic  fragmentation  and  functional  fragmentation. 
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Data  fragmentation  is  a  focus  of  CIC  (Computer  Integrated  Construction) 
research  (Brandon,  &  Betts,  1995).  Electronic  information  sharing  holds  the  promise  to 
overcome  the  inefficiencies  caused  by  fragmentation.  Research  suggests  that  benefits 
from  electronic  information  sharing  include  a  reduction  in  time  requirements  and  errors 
for  data  input  and  output,  accelerated  communication  among  participants,  and  improved 
completeness  of  information  received  by  each  team  member  (Teicholz,  &  Fischer  1994). 
However,  most  current  software  solutions  for  drafting,  scheduling,  estimating  and  project 
document  management  can  only  expedite  the  particular  functionalities  for  which  they 
were  designed.  They  barely  solve  the  problem  of  data  fragmentation  that  leads  to  what  is 
called  "Islands  of  Information"  as  shown  in  Figure  2.1  (Hunnas,  &  Silen,  1995). 

In  summary,  the  construction  industry  has  been  experiencing  problems  of 
information  sharing  at  different  phases  of  construction  due  to  fragmentation  of  this 
industry.  Many  researchers  also  suggest  that  information  technology  will  help  to  solve 
problems  caused  by  fragmentation.  In  the  following  sections,  related  research  studies  and 
applications  are  discussed  in  order  to  propose  an  alternative  approach. 

2.2  Related  Research  Studies 

Integration  is  suggested  as  the  best  approach  to  overcome  difficulties  caused  by 
fragmentation  of  the  construction  industry  (Anderson,  1981,  Ndekugi,  &  McCaffer, 
1988).  A  general  term  to  describe  such  research  activities  is  called  CIC  (Computer 
Integrated  Construction).  CIC  can  be  defined  as  "a  business  process  that  links  the  project 
participants  in  a  facility  project  into  a  collaborative  team  through  all  phases  of  a  project" 
(Teicholz,  &  Fischer,  1994,  pl21). 
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There  are  two  types  of  integration  strategies,  technical  and  managerial  (Fischer,  & 
Kunz,  1995).  Technical  integration  strategy  focuses  on  data  interoperability  of  software 
applications  that  support  different  disciplines.  Managerial  integration  strategy  puts  an 
emphasis  on  the  collaboration  between  a  client  and  various  discipline  specialists,  and 
among  specialists  within  project  teams  or  an  integrated  design-build  organization.  In  fact, 
it  is  argued  that  the  AEC  industry  is  not  able  to  use  IT  (Information  Technology) 
strategically  yet  because  companies  view  IT  as  a  technological  issue,  rather  than  a 
business  issue,  and  thus  delegate  it  to  IT  specialists  (Betts,  1991).  Therefore,  most  of  the 
integration  research  has  been  focusing  on  proposing  technical  solutions  to  overcome 
fragmentation  in  the  AEC  industry  (Howard,  Levitt,  Paulson,  Pohl,  &  Tatum,  1989). 
However,  managerial  integration  is  an  equally  important  aspect  that  is  critical  to  the 
success  of  IT  solutions  (Earl  1989,  Fischer,  &  Breuer,  1995).  The  main  push  in  the  AEC 
research  community  is  to  use  IT  to  "integrate"  different  parties  and  phases  in  the  project 
life  cycle  (Aplegat,  1988,  Howard,  Levitt,  Paulson,  Pohl,  &  Tatum,  1989).  Thus  it  is  clear 
that  parallel  advancement  of  technical  integration  and  managerial  integration  will 
eventually  be  the  way  to  go.  In  this  dissertation,  the  focus  will  be  on  technical  integration 
but  both  technical  integration  and  managerial  integration  will  be  discussed. 
2.2.1  Technical  Integration 

The  purpose  of  technical  integration  is  to  solve  the  problem  of  data 
fragmentation.  Basically  there  are  four  approaches  to  achieve  this  goal  (Rezgui,  Brown, 
Cooper,  Yip,  Brandon,  &  Kirkham,  1996).  They  are  communication  between 
applications,  knowledge-based  interfaces  linking  multiple  applications  and  multiple 
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databases,  integration  through  a  shared  project  model  holding  all  the  information  relating 
to  a  project  according  to  a  common  infrastructure  model,  and  integration  through 
geometry.  In  the  following  sections,  these  approaches  will  be  reviewed  to  find  out 
common  strategies  that  this  research  can  apply. 
Communication  between  Applications 

Communication  between  applications  resorts  to  the  idea  of  a  neutral  data  format. 
This  has  been  already  regarded  as  an  alternative  to  the  shared  project  model  solution 
(Ahmad,  Russell,  &  Abou-Zeid,  1995,  Abou-Zeid,  Russell,  Hanna,  &  Park,  1995).  The 
neutral  data  format  allows  different  software  systems  to  share  data.  Initial  Graphics 
Exchanges  Specifications  (IGES)  is  an  example  of  such  a  neutral  data  format  for  CAD 
systems. 

The  Initial  Graphics  Exchange  Specification  (IGES)  defines  a  neutral  data  format 
that  allows  the  digital  exchange  of  information  among  computer-aided  design  (CAD) 
systems.  CAD  systems  are  in  use  today  in  increasing  numbers  for  applications  in  all 
phases  of  the  design,  analysis,  manufacture  and  testing  of  products.  Since  it  is  a  common 
practice  that  a  designer  uses  one  type  of  CAD  system  and  a  contractor  may  use  a 
different  type  of  CAD  system,  there  is  a  need  for  the  capability  of  exchanging  data 
digitally  among  all  CAD  systems.  IGES  provides  a  neutral  definition  and  format  for  the 
exchange  of  specific  data.  Using  IGES,  a  user  can  exchange  product  data  models  in  the 
form  of  wire  frame  or  solid  representations,  as  well  as  surface  representations. 
Applications  supported  by  IGES  include  traditional  engineering  drawings  as  well  as 
models  for  analysis  and/or  various  manufacturing  ftinctions. 
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One  such  commercial  product  is  the  AutoCAD  IGES  Translator.  The  AutoCAD 
IGES  Translator  (AIT)  is  a  separately  purchased  AutoCAD  Development  System  (ADS)- 
based  application  for  importing  and  exporting  IGES  files.  This  product  supports  the 
IGES  Version  5.2  specification  and  is  compatible  with  AutoCAD  Release  13  and 
AutoSurf  Release  2.1  software.  Figure  2.2  shows  how  it  works. 

IGES 
ii\  Data  k 

CAD  Systems 

Local  I  I 
Data  U 

Figure  2.2  Communication  through  a  neutral  data  format 
Knowledge-Based  Interface 

This  is  one  of  the  early  strategies  for  integration.  The  motivation  of  this  approach 
is  that  "production  expert  systems  for  realistic  engineering  applications  must  process 
large  volumes  of  data  and  will  require  access  to  large  distributed  databases.  The  need  to 
use  expert  systems  when  addressing  larger  problems  motivated  us  to  develop  an  expert 
system  --  DBMS  interface"  (Howard,  «&  Rehak,  1989,  p65).  KADBASSE  was  a  classic 
example  of  such  expert  systems  (Rehak,  &  Howard,  1985,  1989).  The  KADBASE,  a 
knowledge  based  DBMS  prototype,  is  an  interface  in  which  multiple  databases  and 
knowledge-based  systems  can  communicate  as  independent,  self-descriptive  components 
within  a  loosely  coupled  distributed  engineering  computer  system.  Figure  2.3  shows  an 
overview  of  the  KADBASE  architecture. 
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The  KADBASE  is  composed  of  three  parts,  the  Knowledge-Based  System 
Interface  (KBSI),  the  Knowledge-Based  Database  Interface  (KBDBI)  and  the  Network 
Data  Access  Manager  (NDAM).  The  KBSI  formulates  queries  and  updates  sent  to  the 
NDAM  and  processes  replies  from  the  NDAM.  The  KBSI  possesses  knowledge  about  the 
data  space  of  the  whole  system  and  uses  that  knowledge  to  perform  semantic  and 
syntactic  translations  for  queries,  updates  and  replies.  The  KBDBI  is  designed  for 
accepting  queries  and  updates  from  the  NDAM  and  returning  appropriate  replies.  The 
KBDBI  possesses  knowledge  about  the  local  database  schema  and  the  local  language  for 
data  manipulation  requests.  The  KBDBI  uses  that  knowledge  to  perform  semantic  and 
syntactic  translations  for  queries,  updates  and  replies.  The  NDAM  is  the  actual  interface 
between  the  knowledge-based  system  and  the  databases.  It  receives  requests  from 
knowledge-based  systems  (through  their  KBSIs)  expressed  in  terms  of  the  global  schema. 
Using  information  associated  with  the  global  schema,  the  NDAM  locates  sources  for  data 
referenced  in  a  request  and  decomposes  each  request  into  subqueries  or  updates  to 
individual  target  databases.  These  subrequests  are  sent  to  corresponding  KBDBIs  for 
processing.  Replies  from  KBDBIs  are  combined  to  form  a  single  reply  to  the  original 
request  and  sent  to  the  requesting  application  through  its  KBSI. 

The  KADBASE  is  a  typical  example  of  this  approach.  Similarly,  this  type  of 
application  is  applied  to  construction  equipment  management  as  well  (Udo-Inyang,  & 
Chen,  1997). 
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Figure  2.3  The  KADBASE  architecture 
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In  summary,  the  basic  idea  of  the  knowledge-based  interface  approach  is  that  it 
uses  knowledge  systems  to  manipulate  data  that  may  be  located  in  different  databases 
and  maintains  a  global  schema  to  manage  such  data.  In  this  way,  different  databases  for 
drafting,  scheduling  or  estimating  can  be  integrated  and  data  from  different  databases  can 
be  presented  jointly. 
A  Shared  Project  Information  Model 

The  idea  of  a  shared  project  information  model  can  be  traced  back  at  least  to 
Wright.  In  his  paper  "Computer  Integrated  Construction"  (Wright,  1988)  he  discussed  the 
idea  of  an  integrated  project  information  system,  which  he  defined  as  a  dynamic 
repository  for  project-specific  information  that  can  be  appropriately  accessible  to  all 
project  participants.  He  also  discussed  how  this  idea  could  be  implemented  in  the  context 
of  construction  industry.  He  suggested  that  "the  technologies  for  integrated  project 
information  systems  may  themselves  be  proprietary.  Software  packages  and  the  host 
hardware  may  be  commercial  products.  The  provision  of  a  project  informafion  service 
also  can  be  a  private  or  professional  activity.  The  services  can  belong  to  and  be  operated 
by  the  owner  if  the  owner  regularly  builds  and  operates  facilities;  it  can  be  provided  by 
the  contractor  or  by  a  service  bureau  specializing  in  integrated  project  information 
system  service"  (Wright,  1988).  Now,  more  than  ten  years  later,  one  can  see  that  many 
things  that  Wright  "predicted"  in  1988  have  been  implemented  in  the  construction 
industry. 

Ever  since  then,  the  idea  of  the  shared  project  information  model  was  spinning 
around  among  the  academicians.  Figure  2.4  shows  the  typical  shared  project  information 
model  by  project  participants.  This  model  can  also  be  represented  by  different  fiinctional 
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groups  in  the  construction  industry,  such  as  designing,  planning,  scheduling,  estimating 
and  accounting,  shown  in  Figure  2.5.  The  arrows  in  the  diagram  represent 
communication  channels.  They  used  to  be  only  paper-based  documents.  Now  paper- 
based  documents  are  more  and  more  replaced  by  electronic  media  such  as  disk,  CD- 
ROM  and  Web  pages. 

One  of  the  major  advantages  of  the  model-based  approach  is  that  a  model  is 
independent  of  any  particular  implementation  and  any  particular  application.  Therefore 
different  applications  may  eventually  be  able  to  share  the  same  information  model  and 
communicate  with  each  other  via  a  shared  information  model  (Rezgui,  Brown,  Cooper, 
Yip,  Brandon  and  Kirkham,  1996).  Figure  2.5  illustrates  the  idea  of  a  shared  project 
information  model  by  applications.  Examples  of  the  model-based  approach  include 
COKE  (construction  Knowledge  Expert),  OPIS  (Object-model  based  Project 
Information  System),  ATLAS  (Architectures  Methodologies  and  Tools  for  Computer 
Integrated  Large  Scale  Engineering),  COMMIT  (COMputer  Models  for  the  Building 
Industry  in  Europe),  RATAS,  ICON  (Integration  of  Construction  Information)  and  STEP 
(Standard  for  the  Exchange  of  Product  Model  Data). 
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Source:  Fischer,  &  Froese,  1996 

Figure  2.4  The  conceptual  shared  project  information  model 
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Figure  2.5  Shared  project  model 
One  of  achievements  in  this  area  is  the  IFC  (Industrial  Foundation  Classes)  by 
lAI  (International  Alliance  for  Interoperability).  Providing  a  foundation  for  the  shared 
project  model,  IFC  serves  as  an  industrial  standard  for  the  ACE/FM  industry.  There  are 
three  possible  ways  to  share  data  using  IFC  (Wix,  &  See,  1999). 

•  By  creating  a  physical  file  of  information  that  may  be  shared  across  a 
network,  by  email  or  on  a  physical  medium  such  as  a  floppy  disk.  Presently, 
most  software  applications  share  information  using  physical  files. 

•  By  placing  information  in  a  database  that  has  an  interface  defined  according 
to  the  ISO  10303  part  22  (Standard  Data  Access  Interface)  for  putting  in  and 
getting  out  data.  A  number  of  software  applications  are  using  this  approach  at 
present. 

•  By  using  software  interfaces  that  can  expose  the  information  content  of 
defined  groups  of  attributes  within  an  object.  Software  interfaces  allow  for 
direct  communication  between  applications  without  the  need  for  an 
intermediate  file  or  database. 
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Integration  through  Geometry 

Since  this  is  often  the  case  in  CAD  packages  where  integration  is  based  on  and 
only  limited  to  geometrical  information  (Rezgui,  Brown,  Cooper,  Yip,  Brandon  and 
Kirkham,  1996),  this  type  of  integration  will  not  be  elaborated  here. 
Summary  of  Technical  Integration 

It  is  clear  that  the  technical  integration  approaches  discussed  above  can  be 
generalized  into  two  categories.  One  category  represented  by  the  knowledge-based 
interface  approach  features  that  different  systems  share  information  at  a  low  system  level. 
The  second  category  represented  by  communication  between  applications  does  not 
require  different  systems  sharing  anything  at  system  level.  Instead,  different  systems 
communicate  with  each  other  through  a  third  party.  Although  according  to  different 
implementations  the  shared  project  information  model  approach  can  fall  into  both 
categories,  those  implementations  don't  represent  any  new  category. 

Philosophically,  such  generalization  about  technical  integration  is  reasonable 
because  the  problem  is  similar  to  human  communication  using  two  different  languages.  If 
two  people  need  to  communicate  and  they  speak  different  languages,  they  either  find  a 
translator  or  learn  to  use  a  common  language.  The  communication  between  two  computer 
systems  is  a  similar  problem  in  this  sense. 

Furthermore,  in  this  research,  the  approach  of  the  first  category,  i.e.  the  shared 
project  information  model  approach  (using  database  and  using  programming  interfaces) 
and  the  knowledge-based  interface,  is  called  "back-end"  integration.  It  is  called  "back- 
end"  integration  because  the  integration  actually  happens  at  a  low  system  level  and 
applications  are  simply  different  views  to  the  same  database.  For  example,  COMMIT, 
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ICON,  and  RATAS  are  implemented  in  such  a  way  so  that  data  and  information 
generated  within  the  same  package  do  not  have  the  data  fragmentation  problem  at  all. 
The  second  type  is  called  "front-end"  integration  since  integration  happens  at  the  "front" 
of  different  system  that  do  not  share  anything  at  the  system  level.  "Front-end"  integration 
is  based  on  sharing  a  neutral  data  format  that  is  independent  of  any  system. 
2.2.2  Managerial  Integration 

As  discussed  earlier,  managerial  integration  is  as  important  as  technical 
integration.  Currently  managerial  integration  is  focused  on  using  technology,  such  as 
email,  EDI,  conferencing  tools  and  so  on  to  bring  project  participants  together  (Anumba, 
&  Evbuomwan,  1997).  Technically,  managerial  integration  is  intensively  and  extensively 
under  the  subject  of  Computer  Supported  Collaborative  Work  (CSCW).  The  construction 
industry  is  starting  to  pick  up  this  technology  to  support  its  business  and  operation. 

More  than  ten  years  ago,  Paul  Cashman  and  Irene  Grief  organized  a  workshop  of 
people  from  various  disciplines  who  shared  an  interest  in  how  people  work,  with  an  eye 
to  understanding  how  technology  could  support  them.  They  coined  the  term  "Computer- 
Supported  Cooperative  Work"  to  describe  this  common  interest. 

In  1997,  Collaboration  Strategies™  conducted  research  to  examine  how  large 
companies  are  using  IP  networks  (internet  protocol,  i.e.  internet  and  intranets)  to  support 
electronic  collaboration.  Out  of  100  interviews,  85%  of  those  interviewed  responded  that 
the  internet-based  collaboration  is  critical  to  the  functions  of  their  business  (electronic 
collaboration  on  the  internet  and  intranets,  1997).  Among  them  56%  felt  that 
collaboration  was  necessary  to  support  a  distributed  workforce  by  increasing 
communication,  coordination,  facilitation  and  planning.  It  seems  that  the  CSCW  and  the 
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problems  that  this  technology  tries  to  solve  decide  that  the  internet  will  play  a  significant 
role. 

Actually  the  internet  and  intranets  related  CSCW  applications,  especially  the 
Web-related  applications,  are  one  of  the  major  concerns  of  CSCW  research.  Typical 
Web-related  CSCW  applications  includes  collaborative  agent  approaches  (Jin,  &  Ohira, 
1996,  McGraw,  Lawrence,  Morton,  &  Heckel,  1996,  Knapik,  &  Johnson,  1998),  shared 
work-space  approaches  and  work  flow  approaches,  i.e.  Alliance  (Salcedo,  &  Decouchant, 

1997)  ,  BSCW  (Bentley,  Horstmann,  &  Trevor,  1997)  and  WebFlow  (Grasso,  Menunier, 
Pagani,  &  Pareschi,  1997). 

Typical  research  studies  in  the  construction  industry  include  the  virtual 
engineering  team  (Line,  1997),  collaborative  environment  for  resolving  conflicts  and 
disputes  due  to  the  complexity  of  large-scale  project  construction  (Pena-Mora,  &  Wang, 

1998)  ,  collaborative  system  for  managing  design  changes  (Mokhtar,  Bedard,  &  Fazio, 
1998),  collaborative  engineering  for  project  field  inspection  (Rojas,  1997)  and  so  on. 
2.2.3  A  Missing  Piece  between  the  Technical  Integration  and  the  Managerial  Integration 

If  technical  integration  is  regarded  as  a  tool  to  deal  with  data  and  managerial 
integration  as  another  tool  to  deal  with  people,  there  is  still  a  gap  between  the  data  and 
the  people  who  use  the  data.  The  gap  is  how  the  data  can  be  accessed.  This  is  not  an 
active  research  area  because  most  companies  simply  use  standard  documents  for  storing, 
retrieving  and  disseminating  data  and  information.  Even  electronically,  the  gap  is  filled 
by  different  kinds  of  electronic  documents  that  are  very  much  similar  in  format  to  their 
paper-based  counterparts.  However,  if  documents  are  treated  as  ways  for  access  to  other 
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related  information  rather  than  final  presentations  of  data  and  information,  there  are  more 
things  to  do  with  the  documents. 

To  understand  what  else  can  be  done  with  documents,  we  should  take  a  look  at 
how  documents  are  used  and  what  purpose  they  serve  during  project  construction.  During 
the  construction  phase,  information  is  shared  and  disseminated  through  multiple  bi- 
directional communication  channels  (O'Brien,  &  Al-Soufi,  1993,  Fischer,  &  Kunz,  1995, 
Andrew,  &  Teicholz,  1996,  Tierfelder,  WeboUek,  WillenBacher,  &  Grosche,  1997).  The 
media  are  different  kinds  of  documents,  which  are  produced,  stored  and  used  at  separate 
locations,  such  as  change  orders,  shop  drawings,  payroll  reports,  invoice  and  so  on 
(Abou-Aeid,  Russell,  Hanna,  &  Park,  1995,  Ahmad,  Russell,  &  Abou-Zeid,  1995, 
Edwards,  Shaw,  &  Holt,  1996,  Finch,  Flanagan,  &  March,  1996).  According  to  a  survey 
(Edwards,  Shaw,  &  Holt,  1996),  as  much  as  80%  of  corporate  information  is  processed 
through  documents.  It  has  also  been  estimated  that  the  total  number  of  documents  that 
relate  to  a  single  building  structure  may  typically  be  in  the  order  of  10,000  (Turk,  & 
Bjork,  1994).  Consequently  it  is  obvious  that  the  construction  process  demands  timely 
project  documentation  that  can  be  easily  assimilated.  Failure  to  effectively  locate  and 
manage  documents  during  a  project  may  result  in  delay  and  incorrect  decisions  (Finch, 
Flanagan,  &  March,  1996). 

Obviously,  the  documents  are  the  "things"  that  are  actually  shared  by  different 
project  participants  and  are  also  gateways  to  the  shared  or  non-shared  project  information 
sources.  Unfortunately,  not  much  integration  research  addresses  how  construction 
documents  should  be  treated  in  this  context. 
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As  we  know  documents  are  "windows"  to  the  whole  process  and  can  evolve  as 
the  process  does.  No  matter  whether  they  are  paper-based  documents  or  electronically 
generated  documents,  "documents  are  interfaces,  used  to  access  and  navigate  through 
collections  of  information"  (Haimes,  B.,1994,  p.  16).  If  we  look  at  the  whole  information 
source  of  a  project  as  a  reservoir  of  small  information  objects,  documents  provide  a  way 
to  show  the  viewer  the  semantics  of  the  information  objects  and  the  relationships 
between  the  objects.  The  conventional  documents  only  offer  "separated  windows"  to 
viewers,  which  means  it  relies  on  viewers  to  combine  information  acquired  from  the 
"separated  windows"  and  generate  new  knowledge  that  are  not  shown  by  the  "separated 
windows."  The  "separated  window"  is  the  result  of  not  fully  using  the  capacity  of  the 
computer,  since  the  computer  as  a  mediator  has  the  ability  "to  process  and  to  alter  human 
messages  and  to  draw  new  conclusions  regarding  human  messages"  (Chesebro,  & 
Bonsall,  1989,  p.  31).  The  conventional  documents  are  "fixed  windows"  as  well.  The 
perspective  from  which  the  information  objects  and  their  relationships  are  viewed  is  pre- 
set and  fixed  by  the  producers  of  the  documents.  However,  very  often  viewers  need  to 
look  at  the  information  from  another  perspective  based  on  the  viewers'  goals  or 
objectives.  Unfortunately,  the  conventional  documents  are  not  user-centered  and  do  not 
allow  viewers  to  adjust  perspectives  for  their  best  understanding  without  other 
intermediary  processes. 

In  a  word,  the  missing  piece  is  the  construction  document  that  needs  to  be  more 
flexible  to  user's  needs.  Furthermore,  since  it  is  also  a  bridge  between  different  systems 
and  a  gateway  to  different  information  sources,  the  construction  document  can  be  an 
ideal  core  to  build  a  new  integration  strategy  around. 
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2.3  Current  Web-Based  Applications  in  the  Construction  Industry 

The  Word  Wide  Web  has  taken  the  AEC  (architecture  engineering  construction) 
industry  by  storm.  AUhough  it  is  still  hard  to  predict  how  it  will  grow  over  the  next  few 
decades,  the  Web-based  technology  certainly  exerts  great  influence  on  the  AEC  industry, 
A  three-year  study  (Cox,  1996  &  1998,  Cox,  &  Hampson,  1998)  shows  that  the 
improvement  of  the  internet/Web  related  computer  capabilities  reported  by  project 
managers  in  the  USA  has  increased  significantly,  shown  in  Table  2.1. 


Table  2.1  Average  computer  capabilities  reported  by  project  managers 


1996 

1997 

1998 

Average  Rate  of  Increase 

Email 

2.9 

3.4 

40% 

Internet 

1.8 

2.6 

3.1 

72% 

MS  Word 

2.8 

3.5 

3.5 

25% 

Excel 

2.8 

3.5 

3.5 

25% 

L-Notes 

1.7 

3.1 

3.1 

82% 

Timberiine 

1.5 

1.5 

1.9 

27% 

P-3 

2.1 

2.1 

2.3 

10% 

ACAD 

1.8 

1.5 

1.4 

-22% 

Source:  Cox,  1996  &  1998,  Cox  and  Hampson,  1998 


Table2.1  shows  that  the  use  of  email  and  the  internet  has  increased  significantly 
when  compared  with  the  specialized  software  such  as  Primavera  Project  Planning  (P3), 
Timberiine  and  general-purpose  software  such  as  MS  Word  and  Excel.  In  reality,  the 
internet  and  the  Web-related  technologies  penetrated  into  the  daily  operation  of  project 
construction  in  the  early  and  mid  90s  (Wright,  1993,  Setzer,  1994,  Angelo,  1995, 
Schriener,  1995a,  b,  &  c.  Shearer,  1995). 
2.3.1  Major  Application  Types 

Ever  since  the  internet  and  the  Web  have  become  accessible  to  the  public  in  the 
early  90s,  industries  and  academic  institutions  have  embraced  the  technology  quickly  and 
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enthusiastically.  After  almost  a  decade  of  evolvement,  three  types  of  Web-based 
applications  exist  for  the  construction  industry.  They  are  "fee-based  project  management 
service,"  "build  it  yourself  solutions"  and  "Web-enabled  software."  These  applications 
share  the  same  objective,  which  is  to  integrate  the  Web-based  technology  into  project 
construction.  They  are  referred  to  generally  as  project  Website  approaches  in  this 
research. 

Fee-Based  Project  Management  Service 

This  type  of  application  is  relatively  new  to  the  construction  industry.  However, 
theoretical  research  has  already  predicted  the  emergence  of  such  service  in  the 
construction  industry  (Betts,  Cher,  Mathur,  &  Ofori,  1991,  Ahmad,  Russell,  &  Abou- 
Zeid,  1995,  Paulson,  1995).  The  "Fee-Based  Project  Management  Service"  is  for 
companies  that  are  unwilling  or  unable  to  maintain  their  extranets.  There  are  many  such 
service  providers  for  example  e-Builder^"^,  e-Project,  Emerging  Solutions 
(ADVANTAGENET),  BlueLine/OnLine  (ProjectNet),  EVOLV  (ProjectCenter), 
ThePigeonHole  Inc.  (ThePigeonHole),  Cubus  Corp.  (Reviewlt  AEC),  and  Bid-Corn 
(BidCom). 

Build  It  Yourself  Solutions 

Some  AEC  companies  opt  to  develop  their  own  Web-based  project  management 
sites.  For  example,  engineering/construction  firm.  Black  &  Veatch,  was  piloting  the 
Aspects  Project  Server  and  SiteBuilder  collaborative  software  by  Framework 
Technologies  Corporation.  Built  specially  for  the  AEC  community,  SiteBuilder  lets  users 
create  and  update  project  web  sites  while  Project  Server  delivers  collaboration  and 
coordination  functionality  for  project  team  members.  Another  example  is  a  software 
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package  developed  by  a  general  contractor,  Vratsinas  Construction  Company  (VCC). 
VCC  has  developed  a  project  management  system  based  on  Lotus-Notes.  The  system 
helps  professionals  at  job  sites  to  keep  track  of  every  detail  of  daily  construction 
operations.  A  similar  system  has  also  been  developed  by  Zimmer  Gunsul  Frasca  (ZGF),  a 
Portland  based  company.  Although  the  overall  computing,  communication  and 
collaboration  environment  is  improved  greatly  by  deploying  such  systems,  the  "Build  It 
Yourself  Solutions"  requires  lots  of  commitments  that  may  not  be  a  good  idea  for  many 
construction  companies  (Information  Technology,  the  Internet  and  You,  ENR,  June, 
1998).  Nevertheless,  some  companies  such  as  VCC  prefer  this  kind  of  solution  because  it 
allows  them  to  build  applications  that  fit  well  into  their  own  business  environment  and 
maintain  their  own  business  style. 
Web-Enabled  Software 

Companies  such  as  Emerging  Solutions  Inc.  and  Blue-Line/On-Line  not  only 
provide  information  management  services  but  also  sell  their  products  to  allow 
construction  companies  to  maintain  their  own  project  Web  sites.  One  of  the  advantages 
for  companies  administrating  their  own  project  Web  sites  is  that  they  do  not  need  to 
outsource  information.  This  type  of  application  is  especially  good  for  those  companies 
who  are  very  careful  about  letting  other  service  companies  control  their  data  and 
information.  The  disadvantage  is  that  initial  cost  is  relative  high. 

In  addition,  an  increasing  number  of  software  tools  for  estimating,  scheduling, 
drafting  and  project  management  are  offering  Web  ready  features.  This  means  that  from 
within  a  specific  program,  the  user  can  access  and  share  information. 
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Comparison  of  the  Three  Types  of  Applications 

The  differences  between  the  above  three  types  of  appHcations  are  very  obvious. 
They  can  be  simply  distinguished  by  who  built  the  tool  and  who  administered  the  data. 

The  major  common  grounds  of  these  software  tools  in  terms  of  construction 
operations  supported  are  that  they  all  focus  on  establishing  an  on-line  environment  in 
which  project  participants  can  share  information  via  document  exchange.  Typical 
documents  that  those  systems  supports  include 

•  Correspondence 

•  Daily  Report 

•  RFIs 

•  Transmittals 

•  Submittals 

•  Meeting  minutes 

•  Document  Logs 

•  Various  reports 

•  Change  Orders 

•  Purchase  Orders 

To  understand  how  these  Web-based  applications  deal  with  construction 
documents  and  work  with  other  software  tools  such  as  drafting,  scheduling  and 
estimating,  phone  interviews  and  a  Web  search  were  conducted.  The  objective  was  to 
find  answers  two  questions: 
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•  Question  1 :  If  there  is  an  Rf  I  (Request  for  Information)  from  a  third  party 
application,  can  your  system  automatically  retrieve  information  from  sources 
both  within  and  outside  your  computing  environment? 

•  Question  2:  How  will  your  system  deal  with  other  software  tools  such  as 
AutoCAD,  P3  and  Timberline? 

The  results  are  shown  in  Table  2.2. 


Table  2.2  A  comparison  of  some  of  the  major  tools 


Question  1 

Question  2 

AdvantageNet 
Emerging  Solutions  Inc. 

No.  Manual  retrieval 

Build-in  Scheduling 
Features.  Plug-ins  to  other 
tools 

ActiveProject 
Framework  Technologies 

No.  Manual  retrieval 

Plug— ins  to  other  tools 

e-Builder™ 

MP  Interactive  Corp 

No.  Manual  retrieval 

Plug-ins  to  other  tools 

e-Project 

AEC  Online  Inc. 

No.  Manual  retrieval 

Plug-ins  to  other  tools 

ProjectCenter 
Evolv  Inc. 

No.  Manual  retrieval 

Plug-ins  to  other  tools 

ProjectNet 

Blue-Line/On-Line  Inc. 

No.  Manual  retrieval 

Plug-ins  to  other  tools 

ProjectWise 

Workplace  System  Solutions 

No.  Manual  retrieval 

Plug-ins  to  other  tools 

As  shown  in  Table  2.2,  most  of  the  current  Web-based  applications  are  using 
plug-ins  to  work  with  other  software  tools  and  they  also  tend  to  work  with  particular 
software  tools  rather  than  use  vendor  independent  solutions. 
2.3.2  Limitations  of  the  Current  Web-Based  Applications 

One  of  the  advantages  of  using  the  Web  is  that  data  or  information  can  be 
exchanged  much  more  quickly  and  efficiently.  However,  the  construction  software 
market  has  already  been  well  structured  and  dominated  by  many  well-known  brands  and 
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numerous  small  companies.  It  is  very  unlikely  that  one  company  is  able  to  dominate  the 
whole  market;  therefore,  establishing  a  standard  for  document  exchange  over  the  Web  is 
extremely  important. 

Table  2.3  shows  some  major  categories  of  construction  drafting  and  management 
software  companies  and  illustrates  the  large  number  of  players  in  this  market.  Figure  2.6 
shows  the  number  of  software  tools  by  each  of  the  major  vendors  in  each  category.  Table 
2.4  shows  the  major  vendors  in  each  of  the  categories.  Data  and  information  are  obtained 
from  "A/E/C  Systems  The  Magazine  of  Computer  Solutions,"  autumn  1998. 

Figure  2.6  and  Table  2.4  may  not  illustrate  the  whole  picture  of  the  real  world 
because  a  lot  companies  and  products  may  not  have  been  included  in  the  magazine.  The 
numbers  and  the  tables  simply  try  to  show  the  idea  that  the  construction  related  software 
market  has  been  fragmented  by  a  large  number  of  well-established  companies.  Therefore 
it  will  be  very  unusual  if  one  of  them  will  be  able  to  enter  into  all  other  AEC  areas  and 
provide  a  software  package  that  includes  all  kinds  of  applications.  As  long  as  no  software 
vendor  can  monopolize  the  whole  AEC  market,  there  is  a  chance  that  user  software  tools 
may  not  be  compatible. 


Table  2.3  Categories  of  software  companies 


Category 

Meaning 

I 

CAD 

2 

Bidding,  Estimating  &  Job  Costing 

3 

Construction  Management 

4 

Communication  Networking 

5 

Financial  &  Accounting  &  Marketing 

6 

Engineering  Document  Management 

7 

Scheduling  &  Budgeting 

33 


Source:  A/E/C  Systems  The  Magazine  of  Computer  Solutions,  Autumn  1998 
Figure  2.6  Number  of  software  companies  in  each  category 
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Table  2.4  Major  developers  in  each  of  the  major  categories 


Software  Tools 

Major  Developers 

CAD 

Argos  Systems,  IncAutodesk,  Inc.,  Bentley  System,  Inc., 
Building  Blocks,  Inc. ,  CADMAX  Corp,  DataCAD  LLC 

Bidding,  Estimating  & 
Job  Costing 

Bidtek,  Building  Systems  Design,  Inc.,  Computer  Guidance 
Corp.,  Construction  Data  Control,  Inc.,  Dexter  +  Chaney, 
Grantlun  Corp.,  ICARUS,  Management  Computer  Controls, 
Inc.,  McCosker  Corp.,  Meridian  Project  Systems,  Inc. ,  Prosoft 
Inc.,  The  American  Contractor,  The  Construction  Link,  Inc., 
Timberline  Software  Corp. 

Construction 
Management 

Construction  Data  Control,  Inc.,  Computer  Guidance  Corp.,, 
J.D.  Edwards  World  Solutions  Co.,  Management  Computer 
Control,  Inc.,  Merdian  Project  System,  Inc,  Shaker  Computer 
&  Management  Service,  Inc. 

Communication 
Networkmg 

AEC  Online,  Inc.,  Blue-Line/On-Line  Inc., 
Emerging  Solutions,  Inc.,  framework  1  echnoiogies, 
MP  Interactive  Corp. 

Financial  & 
Accounting  & 
Marketing 

Bidtek,  Dexter  +  Chaney,  Deltek  Systems,  Inc. 
McCosker  Corp,  Shaker  Computer  &  Management  Services, 
Inc.,  Solomon  Software,  Inc.,  Timberline  Software  Corp.,  The 
American  Contractor 

Engineering 

Document 

Management 

ACS  Software,  Inc.,  Altris  Software,  CYCO  Intl. 
Computerized  Facility  Integration,  Inc.,  NMT  Corp 

Scheduling  8l 
Budgeting 

AEC  Software,  Inc.,  Data-Maxx  Software  System,  Inc., 
Emerging  Solutions,  Inc.,  Gcon,  Inc.,  The  Paragon  Co., 
Primavera  Systems,  Inc. 

Source:  A/E/C  Systems  The  Magazine  of  Computer  Solutions,  Autumn  1998 
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Put  into  the  context  discussed  above,  one  of  the  limitations  of  the  current  project 
management  Web  site  approach  is  that  most  systems  do  not  effectively  solve  the  data 
interoperability  issue  (See  Table  2.2).  Since  different  vendors  may  use  different  data 
models,  automation  of  document  processing  is  still  impossible  even  if  everybody  is  on 
the  Web.  For  example,  to  process  construction  documents,  a  construction  professional 
usually  needs  to  use  non-shared  project  information  as  well.  The  non-shared  project 
information  is  often  stored  at  least  logically  in  different  sources.  Most  of  the  current 
project  Web  site  approaches  cannot  handle  this  situation  (see  Table  2.2).  Thus  in  this 
case,  the  information  fragmentation  still  exists  because  of  the  different  locations  of  the 
shared  and  the  non-shared  project  information.  In  this  research,  the  non-shared  source  is 
also  referred  to  as  a  local  information  source.  Figure  2.7  shows  the  existence  of  such 
fragmentation. 

From  Figure  2.7,  one  can  see  that  once  a  document  is  received  via  the  Internet 
and  opened  by  a  Web  browser,  that  document  cannot  be  used  directly  to  retrieve 
information  in  the  local  information  sources  because  the  document  received  may  be 
prepared  by  another  third-party  system.  Thus,  in  many  cases,  the  document  viewer  has  to 
manually  interpret  the  document  and  then  go  to  local  information  system  to  retrieve 
related  information.  This  extra  process  is  caused  by  the  gap  between  the  document 
prepared  by  the  third  party  application  and  the  local  information  as  shown  in  Figure  2.7. 
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Figure  2.7  The  existence  of  information  fragmentation  in  the  project  specific  Web  site 
systems 
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2.4  An  Alternative  Solution— Web-Based  "Front-End"  Integration 

Based  on  the  above  discussion,  it  seems  that  an  alternative  strategy  can  be 
achieved  by  focusing  on  two  things,  namely  construction  documents  and  "front-end" 
integration,  over  the  Web.  Construction  documents  are  not  only  the  media  for 
presentation  of  construction  information  but  also  bridges  for  communication  between 
construction  participants.  Effective  management  of  project  documents  is  critical  to  the 
success  of  any  construction  project.  It  is  important  to  notice  here  that  as  far  as  integration 
is  concerned  construction  documents  should  be  an  integral  part  of  the  whole  integration 
strategy.  Moreover,  the  use  of  construction  documents  as  the  core  around  which  the  new 
integration  strategy  can  be  built  will  naturally  lead  to  "front-end"  integration.  By  doing 
so,  the  alternative  approach  uses  system-independent  and  vendor-independent  neutral 
information  models  at  the  "front-end"  (at  the  input/output  level).  By  using  this  alternative 
strategy,  it  is  possible  to  provide  construction  professionals  with  a  more  integrated 
computing  environment  that  the  current  project  specific  Web  site  approach  cannot.  This 
alternative  strategy  is  called  Web-based  "front-end"  integration.  Figure  2.8  shows  the 
concept  of  the  Web-based  "front-end"  integration. 

Comparing  the  difference  between  Figure  2.7  and  Figure  2.8,  it  is  apparent  that 
the  system  shown  in  Figure  2.8  has  an  additional  piece  dealing  with  the  document  and 
related  local  information  before  the  document  is  shown  to  a  user  in  a  Web  browser.  This 
additional  piece,  called  a  "malleable  frame,"  makes  a  construction  document  adjustable 
according  to  the  user's  needs.  Any  system  with  a  "malleable  frame"  will  be  called  a 
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"malleable  frame"  system.  The  "malleable  frame"  is  actually  what  the  Web-based  "front- 
end"  integration  is  all  about. 
2.4.1  A  "Malleable  Frame" 

A  "malleable  frame"  is  a  dynamic  document  template.  Such  a  template  will  define 
a  generic  structure  of  a  particular  type  of  documents  so  that  document  instances  can  be 
generated  according  to  different  situations.  In  the  Web  environment,  a  "malleable  frame" 
differs  from  a  traditional  document  representation  in  such  a  way  that  the  components  of 
the  documents  are  organized  and  represented  in  forms  of  various  information  objects  that 
are  active,  interactive  and  standardized.  In  other  words,  those  information  objects  are 
operable  by  different  systems.  For  example,  a  change  order  may  have  information  objects 
such  as  the  initiator(s),  the  recipient(s),  the  contents,  the  signatures,  etc.  To  be  operable 
by  different  systems,  the  semantics  of  those  information  objects  are  known  to  all 
involved  computer  systems  so  that  they  are  able  to  respond  directly  to  users'  interactions 
no  matter  where  the  systems  are.  For  example,  if  a  change  order  received  changes  the 
size  of  a  door,  the  content  object  of  this  change  order  may  only  have  some  text  about 
"XXX  door,"  which  is  static.  However,  the  "malleable  frame"  has  the  capability  of 
understanding  the  text  "XXX  door"  appearing  on  this  change  order  and  relating  it  to  all 
other  information  objects  related  to  this  "XXX  door"  such  as  its  drawings,  its  cost 
information,  its  material  information  and  so  on.  In  this  way,  the  user  can  manipulate 
objects  of  a  document  effectively. 
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Figure  2.8  The  concept  of  the  Web-based  "front-end"  integration 
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Such  a  dynamic  document  template  has  already  existed  in  PC  systems  where  the 
computing  environment  is  relative  closed.  In  the  Web  envirorunent,  such  a  template  has 
to  be  standardized  in  terms  of  object  semantics  and  it  has  to  be  system  independent  as 
well  so  that  a  document  instance  generated  by  the  template  can  be  portable  to  another 
system.  Therefore  such  a  template  can  also  be  regarded  as  a  neutral  document  format. 

2.4.2  A  "Malleable  Frame"  System 

Any  system  that  incorporates  a  "malleable  frame"  to  generate  document  instances 
and  interpret  document  instances  is  called  a  "malleable  frame"  system.  There  are  two 
types  of  malleability  that  a  "malleable  frame"  system  supports,  namely  vertical 
malleability  and  horizontal  malleability.  Vertical  malleability  exists  when  a  document 
flows  from  one  stage  to  the  next  stage  i.e.  a  stage  transition,  the  information  objects 
contained  in  the  document  are  evolving  and  are  getting  re-organized.  Vertical 
malleability  supports  this  change  by  automatically  identifying,  changing,  managing  and 
juxtaposing  information  objects  for  the  next  stage.  Horizontal  malleability  means  that 
information  objects  of  a  document  can  be  used  directly  by  users  in  order  to  produce  other 
information  objects  for  the  document  of  the  next  stage.  For  any  document  processing, 
vertical  malleability  and  horizontal  malleability  are  complementary  to  each  other. 

2.4.3  Characteristics  of  the  Web-Based  "Front-End"  Integration 
Data  Granularity 

A  "malleable  frame"  is  based  on  the  idea  that  it  is  more  efficient  and  more 
flexible  if  information  can  be  accessed  at  a  lower  level  of  data  granularity  than  the  level 
of  a  document.  Traditionally,  construction  information  is  shared  and  accessed  at  the  level 
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of  a  whole  document  rather  than  any  level  with  smaller  data  granularity.  This  method  of 
sharing  and  accessing  construction  information  results  in  some  inconvenience  when  the 
document  user's  real  interests  may  be  in  the  integration  of  pieces  of  information  from  two 
or  more  documents.  A  better  way  is  to  look  at  a  document  from  a  different  perspective.  If 
we  look  at  a  document  as  a  container  of  different  kinds  of  information  objects,  the 
conventional  documents  can  be  generated  dynamically  in  a  real-time  fashion  by  those 
information  objects.  For  example,  a  request  for  change  order  proposal  (RCOP)  is 
composed  of  information  objects  such  as  the  document  title,  the  sender(s),  the 
recipient(s),  the  date,  the  content  of  document,  attachments,  and  signatures.  The  change 
order  proposal  (COP)  contains  additional  information  about  pricing  and  scheduling  while 
most  information  objects  remain  the  same  as  in  the  RCOP.  Thus  if  the  sharing  occurs  at 
the  information  object  level  rather  than  the  document,  many  information  objects 
contained  in  the  RCOP  and  the  COP  such  as  the  sender(s)  can  be  reused  to  generate 
RCOP  or  COP.  Such  reusability  also  indicates  a  low  semantic  level,  meaning  a  system  is 
now  able  to  understand  each  information  object. 
Effectiveness  and  Efficiency  of  Information  Perception 

The  "malleable  frame"  is  also  based  on  the  idea  that  if  information  can  be 
presented  in  a  way  that  a  viewer  can  easily  relate  the  information  to  his  or  her 
knowledge,  experience,  background  and  so  on,  the  information  can  be  understood  more 
easily. 

As  construction  work  progresses,  as-built  information  is  generated  and  stockpiled. 
All  information,  as-designed  information,  as-built  information,  non-shared  or  any  of  the 
combinations,  is  referenced  frequently  by  different  participants  to  support  their  decision- 
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making  processes.  The  incentive  for  reference  is  triggered  when  uncertainty  rises 
(Weaver,  1949,  Littlejoin,  1983,  D'Ambra,  &  Rice,  1994,  Cragan,  &  Shields,  1998),  or 
there  is  simply  lack  of  information  since  information  is  a  measure  of  uncertainty.  In  other 
words,  information  is  the  number  of  messages  required  to  completely  reduce  the 
uncertainty  in  the  situation  (Littlejohn,  1983).  One  of  the  reasons  that  uncertainty  may 
rise  is  because  project  participants  have  different  goals  (Hendrickson,  &  Tung,  1989  and 
Barrie,  &  Paulson,  1992)  and  the  as-designed,  as-built,  or  non-shared  information  may 
not  quite  explain  the  alternatives  to  achieve  their  goals.  So  the  project  participants  will 
need  extra  information  that  may  be  from  private  sources  or  other  sources. 

The  process  to  reduce  the  uncertainty  is  a  series  of  interactive  communication, 
according  to  uncertainty  reduction  theory  (URT)  (Cragan,  &  Shields,  1998).  The 
communication  can  be  between  two  people,  or  people  and  information  sources.  The 
uncertainty  is  likely  to  be  reduced  more  quickly  if  the  information  represented  can  be 
related  to  a  person's  previous  experience,  knowledge,  or  expertise  (Littlejoin,  1983, 
Devite,  1985). 

We  can  also  look  at  the  problem  from  another  point  of  view,  the  "purposeful 
state"  theory  (Ackoff,  1972).  Information  has  three  levels,  the  technical  level,  the 
semantic  level  and  the  effectiveness  level  (Weaver,  1949).  At  the  effective  level, 
"communication  via  message  affects  the  system  if  it  changes  the  'purposeful  state'  of  the 
organism"  (Littlejoin,  1983,  p.  24).  In  other  words,  information  may  not  be  effective  if  it 
does  not  support  people  to  determine  an  alternative  to  their  goals.  Therefore,  if 
information  from  project  information  sources  cannot  support  a  participant's  specific  goal, 
that  information  is  not  effective  in  this  case.  Since  construction  documents  are  containers 
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and  gateways  of  project  information,  one  way  to  reduce  that  possibility  of  ineffectiveness 
is  to  make  construction  documents  as  malleable  as  possible  to  support  the  goals  of 
different  project  participants. 
A  Web-Based  Approach 

Faster  information  dissemination  requires  a  better  communication  infrastructure. 
Many  studies  and  applications  suggest  using  the  Web  as  a  medium  to  disseminate 
information  (Bentley,  Horstmann,  &  Trevor,  1997,  Bradbury,  1998,  Walch,  Leo,  & 
Antevy,  1998).  The  method  of  using  the  Web  as  a  medium  is  not  new  to  the  construction 
industry  (Schriener,  1995a,  b,  &  c,  Turk,  1995,  Fruchter,  «&  Reiner,  1996,  Liu,  Stumpf,  & 
Chin,  1996,  Brideges,  1997,  Rojas,  1997).  There  are  a  number  of  compelling  reasons  to 
use  the  Web  as  a  communication  medium  (Lynch,  1 996),  one  of  which  is  that  the  Web  is 
a  standard  computing  platform  that  is  an  ideal  tool  for  the  integration  of  data  from 
different  systems. 

2.5  Summary 

Fragmentation  of  the  construction  industry  in  terms  of  the  industry  structure  and 
the  construction  process  has  been  studied  for  a  long  time.  Its  negative  effects  on 
electronic  data  exchange  and  electronic  construction  document  management  have  also 
been  noticed  and  studied  under  the  umbrella  of  CIC  (Computer  Integrated  Construction). 

Integration  has  been  suggested  as  a  way  to  overcome  fragmentation.  There  are 
two  types  of  integration,  technical  and  managerial.  It  is  noticed  that  there  is  another  layer 
between  technical  integration  and  managerial  integration,  which  is  how  data  can  be 
effectively  and  efficiently  accessed.  In  the  construction  industry,  project  participants  rely 
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heavily  on  construction  documents  to  get  information.  This  indicates  that  construction 
documents  can  be  a  focus  of  an  alternative  integration  solution. 

Technical  integration  has  two  strategies.  One  is  that  different  systems  share  a 
common  model  or  common  knowledge  at  low  system  level,  which  is  called  "back-end" 
integration.  The  shared  project  information  model  approach  that  is  implemented  by  a 
shared  database  is  a  typical  example.  The  other  strategy,  which  can  be  called  "front-end," 
is  that  different  systems  communicate  through  a  common  or  neutral  data  format.  They 
may  not  share  anything  at  the  low  system  level.  An  example  of  such  strategy  is  the  IGES 
(Initial  Graphics  Exchanges  Specifications)  translator. 

In  practice,  the  current  project  specific  Web  site  approach  with  three  different 
types  does  not  support  integration  of  different  software  tools.  This  limitation  greatly 
discounts  the  advantages  of  Web-based  applications  since  the  Web  is  designed  for 
improving  data  interoperability. 

Based  on  the  context  discussed  above,  an  alternative  integration  strategy  is 
proposed.  Relying  on  a  "malleable  frame"  and  accordingly  a  "malleable  frame"  system, 
the  alternative  strategy  focuses  on  applying  the  "front-end"  integration  to  Web-based 
construction  documents.  The  following  chapters  will  discuss  details  on  building  a 
"malleable  frame"  and  a  "malleable  frame"  system,  and  testing  the  hypothesis. 


CHAPTER  3 
DEVELOPMENTOF  A  "MALLEABLE  FRAME" 

A  "malleable  frame"  is  basically  the  neutral  format  of  a  construction  document. 
In  the  Web  environment,  such  a  neutral  format  can  be  designed  by  using  XML  (eXtended 
Markup  Language)  technology.  Although  it  is  not  required  by  XML,  a  DTD  (Document 
Type  Definition)  is  normally  used  to  define  the  structure  and  tags  of  a  document.  With  a 
DTD,  a  certain  type  of  document  is  thus  defined.  This  chapter  will  discuss  how  to 
develop  such  a  neutral  format  for  a  Request  for  Change  Order  Proposal  by  using  SGML 
(Standard  Generalized  Markup  Language)  and  XML  technology. 

3.1  A  Brief  Introduction  to  SGML  and  XML 

3.1.1  SGML(Standard  Generalized  Markup  Language) 

SGML,  Standard  Generalized  Markup  Language,  is  an  international  information 
coding  standard.  In  1978,  an  ANSI  (American  National  Standards  Institute)  working 
group  (X3  J6)  was  formed  to  provide  an  unambiguous  format  for  text  interchange  and  a 
markup  language  that  would  be  sufficiently  rich  to  permit  any  processing.  In  the  early 
80s  this  work  was  moved  to  ISO  under  a  working  group  which  is  part  of  SCI  8 
(ISO/IECJTC1/SC18/WG8)  whose  work  later  resulted  in  the  SGML  standard  (Van 
Herwijnen,  1994). 
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One  of  the  major  advantages  of  SGML  is  the  separation  of  document  structure 
and  document  layout.  This  advantage  eventually  makes  SGML  document  portable  among 
different  systems. 

SGML  uses  tags  to  define  information  contained  in  a  document.  There  are  three 
types  of  tagging  schemas,  namely  format  tagging,  structure  tagging,  and  content  tagging. 
HTML  (Hypertext  Markup  Language)  and  XML  apply  format  tagging  and  content 
tagging  respectively. 

SGML  has  developed  some  formal  methods  for  developing  DTDs.  This  research 
will  use  those  methods  to  develop  a  DTD  for  the  Request  for  Change  Order  Proposal. 
3.1.2  XML  (eXtened  Markup  Language) 

Currently,  most  documents  on  the  Web  are  stored  and  transmitted  in  HTML.  As 
mentioned  previously,  HTML  is  a  sub-set  of  SGML  (Standard  Generalized  Markup 
Language)  and  its  tags  are  for  presentation  purposes  mainly.  This  makes  HTML  a  simple 
language  that  is  well  suited  for  hypertext,  multimedia,  and  the  display  of  text  documents. 
However,  the  limitations  of  HTML  become  obvious  as  well,  where  the  semantics  of  a 
document's  content  is  concerned.  Major  limitations  are  extensibility,  structure  and 
validation  (Bosak,  1997,  Microsoft  Corporation,  XML  White  Paper,  1998).  The 
limitations  may  now  be  removed  by  a  new  meta-language,  XML,  which  was  designed  by 
the  W3C  (World  Wide  Web  Consortium)  as  the  next  generation  open  data  format  for  the 
Internet. 

XML  provides  two  major  services.  One  is  the  syntax  for  document  markup  and 
the  other  is  the  syntax  for  declaring  document  structure  (St.  Laurent,  1998).  Such 
services  provide  software  developers  with  a  neutral  layer,  or  a  neutral  data  format,  that 
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can  glue  together  heterogeneous  data  and  applications,  and  provide  end  users  with  a 
much  richer  set  of  Web  applications  for  browsing,  communication  and  collaboration. 

Instead  of  focusing  on  the  presentation  of  information  like  HTML  does,  XML 
focuses  on  the  semantics  of  information  that  is  displayed,  and  separates  the  content  of  a 
document  from  its  presentation  (St.  Laurent,  1998,  Microsoft  Corporation,  XML  White 
Paper,  1998,  Sail,  1997).  In  this  way,  XML  provides  more  user- friendly  applications  by 
allowing  users  to  tailor  presentations  according  to  their  needs.  This  research  will  only 
review  certain  topics  that  are  related  to  this  application.  For  details  about  those 
specifications,  please  visit  the  W3C  Web  site  at  http://www.w3c.org/. 
XML  Specifications 

Formally,  XML  has  three  specifications  (Sail,  1997),  XML  1.0,  XML  linking 
language  and  XML  style  language  (XSL).  However,  several  other  specifications  related 
to  XML  activities  are  proposed  and  recommended  as  well,  such  as  the  Document  Object 
Model  (DOM)  specification,  XML  namespaces,  resource  description  framework  (RDF), 
XML  data  and  XML  vocabularies.  Many  of  the  specifications  are  still  under 
development.  As  of  writing,  the  XML  1.0  and  the  DOM  (recommended)  are  available. 
The  XML  linking  language  and  the  XML  style  language  are  still  at  the  working  draft 
stage  and  the  proposal  stage  respectively. 
XML  Syntax 

XML  uses  an  EBNF  (Extend  Backus-Naur  Form)  syntax  (XML  Specification, 
1997).  An  example  of  the  syntax  for  the  element's  content  is  as  follows: 
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content  ::=  (element 

CharData  |  Reference 

CDSect 

PI  1  Comment)* 

Figure  3.1  A  sample  of  XML  syntax 

XML  Document  Markup 

XML  is  a  subset  of  SGML  therefore  the  document  markup  is  similar  to  SGML. 
The  purpose  of  the  XML  markup  is  to  provide  a  universal  method  for  describing  data. 
There  are  six  kinds  of  markup  that  can  occur  in  an  XML  document  (XML  Specification, 
1997,  Walsh,  1997):  elements,  entity  reference,  comments,  processing  instructions, 
marked  sections  and  document  type  declarations.  Following  are  explanations  of  those 
types  of  markup. 

Elements.  Elements  are  the  most  common  form  of  markup.  They  are  delimited  by 
angle  brackets  and  in  most  cases  used  for  identifying  the  nature  of  the  content  they 
surround.  Some  elements  may  be  empty  in  which  case  they  have  no  content.  If  an 
element  is  not  empty,  it  begins  with  a  start-tag,  <element>,  and  ends  with  an  end-tag, 
</element>. 

Elements  may  have  attributes.  Attributes  are  name-value  pairs  occurring  inside 
tags  after  the  element  name,  e.g.  <projectDocument  type="project  manual">.  In  this 
example,  a  projectDocument  element  has  an  attribute  of  "type"  with  its  value  assigned  to 
"project  manual." 

Entity  Reference.  Some  special  characters  such  as  "<"  are  reserved  for  markup.  In 
order  to  be  able  to  use  them  in  a  document  as  content,  there  must  be  alternative  ways  to 
represent  them.  In  XML,  entities  are  used  to  represent  those  special  characters. 
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Comments.  Comments  in  XML  begin  with  "<!--"  and  end  with  "~  >".  Comments 
can  contain  any  data  except  the  Uteral  string  "— ". 

Processing  Instructions.  Processing  Instructions  (Pis)  are  an  escape  hatch  to 
provide  information  to  an  application.  They  have  the  form:  <?name  pidata?>.  The  name, 
called  the  PI  target,  identifies  the  PI  to  the  application.  In  XML,  the  name  is  "XML".  The 
pidata  is  optional,  such  as  "version="1.0"". 

CDATA  Sections.  A  CD  ATA  section  instructs  a  XML  parser  to  ignore  most  of 
the  markup  characters.  This  is  used  when  the  content  of  a  document  contains  some 
special  characters  such  as  "<".  A  XML  parser  will  otherwise  generate  errors.  A  CDATA 
section  takes  a  form:  <![CDATA[  content  ]]>.  The  only  string  that  is  not  allowed  in  the 
CDATA  section  is  "]]>". 

Document  Declarations.  Document  declarations  allow  a  document  to 
communicate  meta-information  to  the  parser  about  its  content.  Meta-information  includes 
the  allowed  sequence  and  nesting  of  tags,  attribute  values  and  their  types  and  defaults, 
the  names  of  external  files  that  may  be  referenced  and  whether  or  not  they  contain  XML, 
the  formats  of  some  external  (non-XML)  data  that  may  be  included,  and  entities  that  may 
be  encountered.  There  are  four  types  of  declarations  in  XML  (XML  Specification,  1997, 
Walsh,  1997):  element  declarations,  attribute  list  declarations,  entity  declarations,  and 
notation  declarations.  For  example,  an  example  of  element  declarations  is  shown  in 
Figure  3.2.  Element  declarations  identify  the  names  of  elements  and  the  nature  of  their 
element. 
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<!Element  workitem  (description+,  attachment,  reference?)> 
<!Element  description  (#PCDATA|type)*> 

Figure  3.2  A  sample  of  element  declaration 
A  document  declaration  is  mainly  to  tell  the  XML  parser  the  structure  of  a 
document.  An  XML  document  is  valid,  which  means  a  document  type  definition  (DTD) 
is  associated,  or  be  well  formed,  which  means  a  DTD  is  not  required  and  the  document 
obeys  the  XML  syntax  (Sail,  1997,  XML  Specification,  1997,  Walsh,  1997).  The 
structural  information  of  documents  are  therefore  explicitly  declared  by  DTDs 
(Document  Type  Definition)  or  implicitly  declared  by  documents  themselves  (a  well- 
formed  document). 

3.2  A  Sample  Construction  Document 

3.2.1  Construction  Change  Order  and  Change  Order  Processing 

Without  change  orders,  most  projects  could  not  be  timely  and  efficiently 
completed.  Changes  can  occur  for  many  reasons  that  include  the  foUowings  (Mincks,  & 
Johnston,  1998): 

•  Owner  directed  change  of  scope.  Extra  work  is  added  to  or  deducted  from  the  project 
and  it  is  clearly  a  change  of  scope  to  the  contract. 

•  Constructive  change.  The  architect  or  owner  representative  causes  the  contractor  to 
perform  work  outside  his  contract. 

•  Consequential  change.  This  occurs  as  a  consequence  of  the  preceding  two  changes. 

•  Differing  site  conditions.  This  change  applies  to  differing  subsurface  conditions  than 
are  indicated  by  contract  documents  or  are  available  from  geotechnical  reports. 
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•    Jobsite  discovery  of  hazardous  materials.  This  often  causes  work  to  stop. 

According  to  different  situations,  changes  can  be  made  at  no  cost  and  with  no 
change  in  duration,  or  can  result  in  greater  or  less  costs  and  require  an  addition  or  a 
reductionin  contract  time. 

The  whole  change  order  process  consists  of  several  steps,  one  of  the  important 
steps  for  contractors  is  to  return  a  change  order  proposal.  Figure  3.3  shows  the 
information  flow  of  this  step. 


No  Cost 


Budget 
Drawings 
Schedule 
Specification 


Cost  Change 


Estimating  / 

Subquotes 

 1 

COP 


Figure  3.3  The  step  to  produce  a  Change  Order  Proposal 
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3.2.2  A  Request  for  Change  Order  Proposal 

From  Figure  3.3,  one  can  see  that  quickly  and  efficient  processing  a  Request  for 
Change  Order  Proposal  is  the  key.  There  are  standard  documents  i.e.  the  American 
Institute  of  Architects  (AIA)  documents,  the  Engineers  Joint  Contract  Document 
Committee  (EJCDC)  documents,  the  Construction  Specification  Institute  (CSI) 
documents  and  the  Associated  General  Contractors  of  America  (AGC)  documents.  There 
are  also  countless  customized  documents  by  different  contractors.  A  sample  documents 
of  "Request  for  Change  Order  Proposal"  is  shown  in  the  Appendix  A. 

3.3  Methodology  for  Developing  A  Document  Type  Definition  (DTD) 

3.3.1  Phases  of  Development 

A  complete  process  of  developing  a  DTD  usually  has  several  phases.  Figure  3.4 
shows  a  six-step  model  of  developing  DTD.  This  chapter  will  develop  a  DTD  for  a 
Request  for  Change  Order  Proposal,  following  phase  2,  3  and  4.  The  approaches  used 
here  are  replicable  so  that  other  construction  documents  can  be  developed  in  the  same 
way. 

In  this  chapter,  phase  2  and  3  will  be  discussed  in  detail  to  develop  a  DTD  for  a 
request  for  change  order  proposal. 

Phase  2  normally  includes  three  steps: 

1 .  Identify  and  define  the  basic  information  elements  that  markup  must  encode 

2.  Classify  the  elements  into  logical  groups 

3.  Validate  the  analysis  against  other  models  that  have  already  been  developed 
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Phase  1 :  Define  goal 


r 

Phase  2:  Analyze  needs 

r 

Phase  3:  Design  document  type  requirements 

Phase  4:  Complete  the  design  of  DTD  and  implement  it 

Phase  5:  Test  the  outputs  of  the  DTD 

 I  

Phase  6:  Document  the  DTD  and  train  people  to  use  it 


Source:  Maler,  &  Andaloussi,  1996 

Figure  3.4  Phases  for  developing  DTD 
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Construction  documents  have  already  been  well  studied,  formatted  and 
standardized,  therefore  what  need  to  be  done  are  simply  to  collect  construction  document 
samples  and  classify  information  contained  by  those  samples.  A  sample  construction 
documents  is  included  in  Appendix  A. 

Based  on  the  elements  identified  in  Phase  2,  Phase  3  will  focus  on  building  a 
document  model.  This  model  can  be  represented  by  one  of  the  formal  methods,  i.e.  the 
tree  diagram,  the  railroad  model  and  the  elm  tree  diagram.  Another  issue  in  this  phase  is 
to  define  attributes  of  each  element.  Since  the  attribute  list  of  each  element  can  include 
almost  everything,  this  research  only  focuses  on  attributes  of  some  particular  elements. 
3.3.2  Models  for  Illustrating  Document  Structure 

A  key  step  in  DTD  development  is  to  develop  a  document  model  that  illustrates 
the  structure  of  a  document.  There  are  many  different  types  of  developing  approaches, 
i.e.  tree  diagrams,  box  diagrams,  sample  marked-up  pages,  railroad  model  diagrams,  and 
elm  tree  diagrams  ("elm"  stands  for  "enables  lucid  models").  Tree  structures,  box 
diagrams  and  sample  marked-up  pages  are  used  for  representing  instances  of  a  model, 
not  the  model  itself  (Travis,  &  Waldt,  1995).  The  elm  tree  diagram  improves  the  tree 
structure  approach  by  incorporating  SGML  properties  into  the  document  structure 
represented  as  a  tree.  The  railroad  model  diagram  is  a  method  to  model  a  document 
generically.  This  research  will  use  the  railroad  model  diagram  to  develop  a  document 
model  of  a  Request  for  Change  Order  Proposal.  Suppose  that  there  is  a  recipe  structured 
as  shown  in  Figure  3.5: 
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Recipe 

Title 

Ingredient  list 

Ingredient(s) 

Instruction  list 
Step(s) 


Figure  3.5  A  sample  structured  document 
The  graphical  representations  of  the  structured  document,  three  types  of 
diagrams,  the  tree  diagram,  the  railroad  model  and  the  elm  tree  diagram,  are  illustrated 
for  comparison  in  Figure  3.6  -  3.8. 


Ingredient 


Step 


Source:  Maler,  &  Andaloussi,  1996 


Figure  3.6  A  tree  structure 
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Recipe: 


Title 

Ingredient  list 

 ► 

Ingredient  list 

 ► 

Ingredient  list: 


r 

Ingredient 

Instruction  list: 


Step 

Source:  Maler,  &  Andaloussi,  1996 

Figure  3.7  A  railroad  model  structure 


Title 

#PCDATA 


Recipe 


Type 
servings 
preptime 


Ingredient  list 


Instruction  list 


+ 


Ingredient 


Necessary 
=  (yes  I  no) 


+ 


Step 


#PCDATA 


#PCDATA 


Source:  Maler,  &  Andaloussi,  1996 


Figure  3.8  A  elm  tree  structure 
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3.3.3  Railroad  Model  Diagrams 


There  are  seven  basic  structures  of  railroad  model  diagrams,  see  Figure  3.9. 


Basic  Structure 

Meaning 

a 

 ► 

One  element  a  that  appears  once 

a 

 ► 

h 

 ► 

One  element  a  followed  by  an  element  b. 
Both  appear  once  and  a  precedes  b. 

a 
b 

 ► 

One  element  a  or  one  element  b.  Exactly 
one  of  them  will  appear  but  not  both. 

a 
b 

h 

a 

 ► 

One  element  a  followed  by  one  element  b 
or  one  element  b  followed  by  one  element 
a.  This  means  both  elements  must  appear  in 
arbitrary  order. 

At  least  one  element  a  roUowed  by  any 
number  of  a's.  In  other  words,  a  must 
appear  at  least  once. 

r 

a 

a 

An  optional  element  a. 

V 

r 

a 

An  undetermined  number  of  elements  a 

I 

Source:  Van  Herwijnen,  1994 


Figure  3.9  Basic  structures  of  railroad  model  diagrams 
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A  terminal  element  is  represented  with  a  triangle  in  the  bottom  right  hand  comer, 
as  shown  in  Figure  3.10. 


a 

 ► 

Figure  3.10  A  terminal  element 
3.4  A  DTD  for  A  Request  for  Change  Order  Proposal 

Developing  a  DTD  for  a  Request  for  Change  Order  Proposal  involves  defining 
the  structure  of  a  Request  for  Change  Order  Proposal.  This  DTD  will  serve  as  a  guideline 
to  develop  a  Request  for  Change  Order  Proposal  in  a  XML  (neutral)  format.  Such  a 
document  in  the  neutral  format  will  then  be  used  to  show  the  malleability  of  the 
"malleable  frame"  system. 
3.4.1  Document  Analysis 

There  are  many  samples  of  Request  for  Change  Order  Proposals.  These  samples 
can  be  standard  documents  or  non-standard  documents.  Appendix  A  includes  one  sample 
of  Request  for  Change  Order  Proposals. 

However,  these  samples  normally  do  not  show  what  types  of  information  are 
included  in  "Description".  To  determine  that,  two  samples  from  an  actual  construction 
project  are  used. 
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Sample  One: 
DESCRIPTION: 

REVISION  TO  DOOR  AT  CLOSET  4-220 

Relocate  door  4-22  IB  to  open  to  the  corridor  side  or  opposite  side  of  the 
closet  as  shown  on  the  attached  sketch.  Reverse  the  light  switch  so  that  it 
is  accessible  on  the  right  hand  side  of  the  door  upon  entering  the  revised 
closet.  The  hardware,  door  and  frame  remain  the  same. 

Sample  Two: 

DESCRIPTION: 

CHILLED  WATER  FOR  PHASE  II 

Provide  chilled  water  capped  in  the  ceiling  on  the  third  floor  of  the  new 
patient  tower  connector  as  requested  by  the  GRGV's  PR#M09  (note: 
drawing  number). 

Figure  3.11  Sections  of  construction  document  samples 
From  these  two  examples,  it  is  obvious  that  normally  the  content  of  the 
"Description"  should  at  least  include 

•  The  building  component(s)  involved  in  the  document 

•  The  other  related  building  component(s) 

•  Related  drawings 

•  Related  specifications 

•  Descriptions  about  the  request 

•  Actions  expected 

•  Other  related  information 


60 

In  addition  the  elements  identified  above,  this  research  distinguishes  between 
three  types  of  information,  i.e.  project  information,  document  information  and  document 
content.  Table  3.1  shows  information  included  in  each  of  the  types. 


Table  3.1  Information  typically  contained  in  a  Request  for  Change  Order  Proposal 


Type 

Information 

Project  Information 

Project  Name,  Project  Number,  Contract  Date,  Owner  (Name, 
Address,  Phone,  Fax,  Web  Address,  etc).  Architect  (Name, 
Address,  Phone,  Fax,  Web  Address,  etc) 

Document 
Information 

From,  To,  Document  Number,  Document  Date,  Check  List 
(Architect,  Owner,  Contractor,  Consultant  and  Other), 
Document  Notice  and  Description,  Signatures  and  Others 

Document  Content 

Item  Name,  Description  (main  component(s),  related 
component(s),  conditions  and  actions).  Drawings, 
Specifications,  Others 

3.4.2  A  Document  Model  For  A  Request  for  Change  Order  Proposal 

Using  the  railroad  model  diagram,  the  document  model  of  a  Request  for  Change 
Order  Proposal  can  be  represented  by  railroad  model  diagrams.  Although  Table  3.1 
shows  a  summary  of  information  contained  in  a  Request  for  Change  Order  Proposal,  it 
does  not  show  the  structure  of  the  document.  A  railroad  model  diagram  shows  not  only 
what  information  is  included  in  the  document,  but  also  the  structure  of  how  the 
information  is  composed  to  form  the  document.  Thus  such  a  diagram  is  a  bridge  between 
a  document  and  a  DTD.  Figure  3.11-3.17  show  the  document  models  of  a  Request  for 
Change  Order  Proposal  (RCOP). 
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Project 
Information 


RCOP 


Document 
Information 


Document 
Information 


Project 
Information 


Document 
Content 


Figure  3.11  Root  element  of  a  RCOP 


Project  Information:  (Since  there  are  four  elements,  in  total  there  will  be  32 
permutations  to  show  the  sequence  of  the  elements  is  arbitrary.  To  make  it  simpler, 
the  following  diagram  will  use  dot  lines  to  represent  such  relationship). 


Project 
Name 

Project 
Number 

Contract 
Date 

Project 
Parties 

 ► 

Figure  3.12  Project  information  element  of  a  RCOP 


Project  Parties 


Architect 


Owner 


Contractor 


Others 


Architect,  Owner,  Contractor  and  Others 


Name 

Address 

Phone 

Fax 

 ► 
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Project  Name,  Project  Number,  Contract  Date,  Name,  Address,  Phone  and  Fax 


Label 
Name 

Label 
Value 

 ► 

Figure  3.13  Sub-elements  of  project  information  of  a  RCOP 


Document  Information 


Sender 

Recipient 

Document 
Number 

Document 
Date 

Checklist 

Document 
Notice 

Signature 

w 

Figure  3.14  Document  information  element  of  a  RCOP 


Sender,  Recipient,  Document  Number,  Document  Date,  Document  Notice, 
Signature,  Others 


Label 
Name 

Label 
Value 

 ► 

Figure  3.15  Sub-elements  of  document  information  of  a  RCOP 
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Document  Content 


Item 

Description 

Name 

 ► 

r 

Others 
Info 

i 

Figure  3.16  Document  content  element  of  a  RCOP 


Description 


Main 
Component 
or  Activity 


Related 
Component 
or  Activity 


Conditions 


Actions 


Figure  3.17  A  sub-element  of  document  content  of  a  RCOP 
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3.4.3  A  DTD  for  The  Request  for  Change  Order  Proposal 

With  the  clear  definition  of  the  structure  of  a  Request  for  Change  Order  Proposal, 
this  section  will  convert  the  graphic  diagrams  into  a  DTD  that  is  shown  in  Figure  3.18. 
The  meaning  of  some  symbols  used  in  the  Figure  3.18  are  explained  in  Table  3.2  and  3.3. 


Table  3.2  Occurrence  Indicators 


Symbol 

Meaning 

(nothing) 

Sequence,  required,  one  must  occur 

7 

Optional,  zero  or  one  can  occur 

+ 

Required  and  repeatable,  one  or  more  must  occur 

* 

Optional  and  repeatable,  zero  or  more  may  occur 

Table  3.3  Connectors 

Symbol 

Meaning 

Is  followed  by 

0 

Grouping 

Or,  one  of  the  elements  in  the  group  may  occur 

& 

And  ,  all  must  occur  in  any  order 
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<?XML  verion="1.0"  ?> 

<!DOCTYPE  document  SYSTEM  "RCOP.dtd"> 
<!--  ELEMENT  DECLARATION  — > 

<!ELEMENT  document  (projectlnfo  &  documentlnfo  &  documentContent)  > 

<! ELEMENT  projectlnfo  (projectName  &  projectNumber  &  contractDate  &  projectParties)> 

<!ELEMENT  documentlnfo  (sender  &  recipient  +  &  documentNumber  &  documentDate 

&  checklist  &  documentNotice  &  signature  +)> 
<!ELEMENT  documentContent  (itemName,  description  ,  (drawings  *  &  specifications* 

&  others  *)*)+> 


ELEMENT  projectName  (labelName,  labeIValue)> 

ELEMENT  projectNumber  (labelName,  labelValue)> 

ELEMENT  contractDate  (labelName,  labelValue)> 

ELEMENT  projectParties  (architect  &  owner  &  contractor  &  others*  )> 

ELEMENT  architect  (name,  address,  phone,  fax)> 

ELEMENT  owner  (name,  address,  phone,  fax)> 

ELEMENT  contractor  (name,  address,  phone,  fax)> 

ELEMENT  others  (name,  address,  phone,  fax)> 

ELEMENT  name  (labelName,  labelValue)> 

ELEMENT  address  (labelName,  labelValue)> 

ELEMENT  phone  (labelName,  labelValue)> 

ELEMENT  fax  (labelName,  labelValue)> 

ELEMENT  others  (labelName,  labelValue)> 

ELEMENT  sender  (labelName,  labelValue)> 

ELEMENT  recipient  (labelName,  labelValue)+> 

ELEMENT  documentNumber  (labelName,  labelValue)> 

ELEMENT  documentDate  (labelName,  labelValue)> 

ELEMENT  signature  (labelName,  labelValue+)> 

ELEMENT  checklist  (cl  architect,  cl_owner,  cl  contract,  cl_consultant,  cl_other)> 

ELEMENT  cl_architect  (labelName,  labelValue)> 

ELEMENT  cl_owner  (labelName,  labelValue)> 

ELEMENT  cl_contractor  (labelName,  labelValue)> 

ELEMENT  cl_consultant  (labelName,  labelValue)> 

ELEMENT  cl_other  (labelName,  labelValue)> 

ELEMENT  documentNotice  (#PCDATA)> 

ELEMENT  labelName  (#PCDATA)> 

ELEMENT  labelValue(#PCDATA)> 

ELEMENT  itemName  (#PCDATA)> 

ELEMENT  description  (mainComponent,  relatedComponent  *,  condition,  actions?)> 

ELEMENT  drawings  (#PCDATA)> 

ELEMENT  specifications  (#PCDATA)> 

ELEMENT  otherslnfo  (#PCDATA)> 

ELEMENT  mainComponent  (#PCDATA)> 

ELEMENT  relatedComponent  (#PCDATA)> 

ELEMENT  conditions  (#PCDATA)> 

ELEMENT  actions  (#PCDATA)> 


Figure  3. 1 8  A  DTD  for  a  Request  for  Change  Order  Proposal 
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<!—  Attribute  Declaration  -> 

<!ATTLIST  document 

type  CDATA 

#required> 

<!ATTLIST  itemName 

gid  ID 

#required> 

<!ATTLIST  mainComponent 

key  CDATA 

#required 

reference    (yes  no) 

'yes'  > 

<!ATTLIST  relatedComponent 

key  CDATA 

#required 

reference    (yes  |  no)  'yes' 

> 

<!ATTLIST  drawings 

key  CDATA 

#required 

attachment  (yes  no) 

#implied 

reference     (yes  no) 

'yes'  > 

<!ATTLIST  specifications 

key  CDATA 

#required 

attachment  (yes  no) 

#implied 

reference     (yes  no) 

'yes'  > 

Figure  3.18  Continued 


This  section  discusses  how  to  present  a  construction  document  in  the  right  format, 
i.e.  the  DTD  of  the  construction  document,  so  that  a  computer  can  understand  what  the 
document  is  and  what  information  is  included  in  the  document.  Furthermore,  if  the  DTD 
and  the  associated  tags  are  standardized,  different  computer  system  can  share  the 
semantics  of  the  document.  However,  one  problem  that  has  not  yet  been  discussed  deeply 
enough  in  this  section  is  that  how  the  information  in  the  document  can  be  used  to  retrieve 
information  in  a  document  viewer's  local  system.  This  problem  will  be  discussed  in  the 
next  chapter. 

3.5  The  Request  for  Change  Order  Proposal  in  XML  Format 

Based  on  the  DTD  above,  the  sample  document  for  Request  for  Change  Order 
Proposal  can  be  written  in  XML  format,  which  is  shown  in  Figure  3.19. 
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3.6  Summary 

The  malleability  is  actually  achieved  by  two  factors,  a  structured  document  in  a 
neutral  format  and  a  system  that  can  interpret  the  document.  This  chapter  discussed  how 
to  convert  a  typical  construction  document,  a  Request  for  Change  Order  Proposal,  into 
XML  format.  This  is  achieved  by  using  a  formal  method  to  develop  a  DTD  of  a  Request 
for  Change  Order  Proposal.  Based  on  the  DTD,  instances  of  such  a  document  can  be 
derived.  The  development  of  the  DTD  in  this  dissertation  uses  a  top  down  approach  that 
is  based  on  sample  documents  to  develop  document  requirements.  A  DTD  can  be 
developed  by  a  bottom  up  approach  as  well,  by  which  data  models  such  as  IFC 
(Industrial  Foundation  Class)  data  models  can  be  used  to  define  objects  and  relationships 
between  objects.  A  DTD  then  can  be  generated  according  to  the  data  models. 

In  addition,  the  DTD  also  provides  a  hyperbase  indicating  what  types  of 
information  elements  are  included,  the  hierarchy  that  those  elements  form,  and  what 
kinds  of  relationships  exist  between  those  elements.  Such  analysis  will  be  used  for 
developing  a  hypermedia  system  later  in  the  next  chapter. 
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<?xml  version="1.0"?> 
<document  type="changeRequest"> 

<projectInfo> 

<projectName>Flagler  Hospital</projectName> 

<porjectNumber>94345</projectNumber> 

<contractDate> 

<labelName>Contract  Date</lableName> 

<labelValue>  1 998-8- 1 2</lableValue> 
</contractDate> 

<projectParties> 

<architect> 

<name>Albert  Design</name> 

<address>2345  NW  345  Rd.,  Gainesville,  FL  32445</address> 

<phone>(352)  1 234567</phone> 

<fax>(352)7653432</fax> 
</architect> 
<owner> 

<name>University  of  Florida</name> 

<address>2345  NW  345  Rd.,  Gainesville,  FL  32445</address> 

<phone>(352)  1 234567</phone> 

<fax>(352)7653432</fax> 
</owner> 
<contractor> 

<name>Gator  Construction</name> 

<address>2346  NE  35  St,  Gainesville,  FL  32465</address> 

<phone>(352)8769 1 52</phone> 

<fax>(352)5869435</fax> 
</contractor> 
</projectParties> 
</projectInfo> 

<documentInfo> 
<sender> 

<labelName>ARCHITECT</labelName> 
<labelValue>Albert  Design</labelValue> 
</sender> 

<recipient> 

<labelName>CONTRACTOR</labelName> 

<labelValue>Gator  Construction</labelValue> 
</recipient> 


Figure  3.19  A  Request  for  Change  Order  Proposal  in  XML  Format 
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<documentNumber> 

<labelName>Proposal  ID</labelName> 

<labelValue>23</labelValue> 
</documentNumber> 

<documentDate> 

<labelName>Proposal  Date</labelName> 

</labelValue>  1 998- 1 2- 1  </label  Value> 
</documentDate> 

<checklist> 

<cl_architect> 

<labelName>ARCHITECT</labelName> 
<labelValue>AIbert  Design</labelValue> 

</cl_architect> 

<cl_owner> 

<labelName>OWNER</labelName> 
<labelValue>University  of  Florida</labelValue> 

</cl_owner> 

<cl_contractor> 

<labelName>CONTRACTOR</labelName> 
<labelValue>Gator  Construction</labelValue> 

</cl_contractor> 
</checklist> 

<documentNotice> 

Please  submit  an  itemized  quotation  for  changes  in  the  Contract  Sum 
and/or  Time  incidental  to  proposed  modifications  to  the  Contract 
Documents  described  herein.  All  items  listed  below  may  be  clarifications 
only  without  affecting  cost  or  schedule. 

</documentNotice> 

<signature>xxx</signature> 
</documentInfo> 

<documentContent> 

<itemName  gid="15_001">CHILLED  WATER  FOR  PHASE  II</itemName> 
<description> 

<mainComponent>chilled  water  for  phase  II</mainComponent> 
<condition> 

Provide  chilled  water  capped  in  the  ceiling  on  the  third  floor  of  the  new 
patient  tower  connector  as  requested  by  the  GRGV's  PR#M09 
</condition> 
</description> 

<drawing>M09.gif</drawing> 
</ documentContent> 

</document> 


Figure  3.19  Continued 


CHAPTER  4 
"MALLEABLE  FRAME"  SYSTEM  DESIGN 

In  Chapter  3,  the  development  of  a  DTD  (Document  Type  Definition)  is 
discussed.  Such  a  DTD  is  in  fact  what  makes  a  document  malleable.  Serving  as  a  generic 
document  template  a  DTD  defines  the  structure  of  the  information  elements  of  a 
document,  and  the  semantics  of  those  information  elements,  therefore  if  a  DTD  is  shared 
by  different  systems,  those  systems  will  be  able  to  interpret  the  same  document  exactly 
the  same  way.  Besides,  since  a  DTD  defines  each  element  of  a  document,  different 
systems  will  then  share  the  meaning  of  document  up  to  the  element  level.  That  is  how 
one  system  can  manipulate  a  document  prepared  by  another  system. 

Besides  such  a  DTD,  tools  need  to  be  available  for  users  to  take  advantage  of 
malleability.  This  chapter  will  concentrate  on  the  discussion  of  the  design  of  such  tools,  a 
"malleable  frame"  system.  There  are  two  major  issues,  which  are  the  design  of  the 
system  structure  that  has  malleability  and  the  application  of  a  standard  construction 
information  classification  system  that  can  be  used  to  search  and  retrieve  local 
information.  This  research  will  assume  that  such  an  information  classification  system  is 
available,  i.e.  the  CSI  Masterformat,  to  simplify  the  problem. 

4. 1  Methodologies  for  Developing  Hypermedia  Systems 

A  "malleable  frame"  system  is  a  Web-based  hypermedia  system  by  nature 
therefore  this  section  will  first  review  some  major  methodologies  of  hypermedia  design 
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Methodologies  for  hypermedia  development  have  already  been  studied  and  well 
documented  in  the  past  ten  years.  One  of  the  major  development  philosophies  is  the 
separation  of  design  and  production  (Garzotto,  Paolini,  &  Schwabe,  1993).  Although  not 
clearly  discussed  in  the  early  design  methodologies,  "hypermedia  development  often 
faces  two  major  tasks.  One  is  called  author-in-the-large,  which  focuses  on  the 
specification  and  the  design  of  the  global  and  structural  aspects  of  a  hypertext 
application.  The  other  task  is  called  author-in-the-small,  which  focuses  on  the  contents  of 
nodes"  (Garzotto,  Paolini,  &  Schwabe,  1993).  The  identification  of  the  two  different 
tasks  finally  leads  to  the  separation  of  the  specification  design  and  the  implementation. 
However,  the  two  tasks  are  typically  very  interwoven.  The  design  deliverable  is  not  a 
hypermedia  document  but  rather  a  specification  book  that  is  handed  to  a  production  team 
to  be  implemented.  As  a  result,  major  design  approaches  and  implementation  approaches 
will  be  discussed  separately  as  well. 

The  most  influential  examples  of  early  hypermedia  design  methods  are  probably 
the  g-IBIS  (Conklin,  &  Begeman,  1988)  and  the  Dexter  Hypertext  Reference  Model 
(Halasz,  &  Schwartz,  1990,  Halasz,  &  Schwartz,  1994).  The  early  development  efforts, 
such  as  the  Dexter  Hypertext  Reference  Model,  tried  to  abstract  all  existing  hypertext 
systems  in  order  to  provide  a  basis  for  description,  comparison  and  interchange.  Later 
approaches,  such  as  the  HDM  (Hypertext  Design  Model)  (Garzotto,  Paolini,  &  Schwabe, 
1993),  the  RMM  (Relationship  Management  Methodology)  (Isakowitz,  Stohr,  & 
Balasubramanian,  1995)  and  the  OOHDM  (Object-Oriented  Hypertext  Development 
Methodology)  (Schwabe,  Rossi,  &  Barbosa,  1996),  have  distinct  characteristics.  Those 
approaches  "choose  not  to  represent  all  aspects  of  the  existing  systems  but  instead 
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present  a  particular  and  logically  consistent  view  of  hypertext  that  satisfies  a  particular 
goal  and  separate  design  from  implementation"  (Garzotto,  Paolini,  &  Schwabe,  1993, 
pp5).  Most  current  application  designs  can  find  their  roots  from  the  above  three 
approaches. 
4.1.1  HDM 

HDM,  with  a  goal  of  supporting  specification  design,  provides  means  for 
describing  application  schemas,  which  in  turn  can  then  be  used  to  generate  different 
instances.  To  facilitate  the  specification  design,  HDM  has  a  set  of  terms  and  concepts 
called  HDM  primitives  for  describing  a  hypertext  application.  The  HDM  primitives  and 
design  methodology  will  be  discussed  briefly  in  the  following. 
HDM  Primitives 

HDM  primitives  include  entity,  component,  unit,  perspective,  and  links.  An  entity 
is  a  structure  of  information  that  represents  some  real  world  objects  of  an  application 
domain,  such  as  a  construction  document.  An  entity  has  an  entity  type,  for  example, 
"construction  document"  is  the  entity  type  of  a  construction  document.  One  of  the 
important  characteristics  of  an  entity  is  that  its  existence  does  not  depend  on  other 
entities.  An  entity  is  a  hierarchy  of  components  arranged  in  a  tree-like  fashion.  For 
example,  a  construction  document  may  have  "Contractor"  as  one  of  its  components.  A 
component  in  turn  is  made  of  units.  Each  unit  is  an  actual  container  of  information  for  the 
corresponding  component.  A  unit  is  characterized  by  a  name  (its  identifier)  and  a  body. 
Bodies  of  unites  are  places  where  the  actual  content  of  an  application  is  filled  in.  For 
example,  "name/Bechtel"  is  one  of  the  units  of  the  component,  "Contractor". 
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Usually,  each  unit  shows  the  content  of  a  component  under  a  particular 
perspective.  In  HDM,  perspective  captures  the  notion  of  having  different  presentations 
for  the  same  content.  For  example,  in  hypermedia  applications  different  media,  such  as 
text,  graphic,  video,  sound,  etc.,  are  very  often  used  for  presenting  the  same  pieces  of 
information.  Each  of  those  presentation  methods  is  a  particular  perspective. 

HDM  has  three  types  of  links:  perspective  links,  structural  links,  and  application 
links.  Perspective  links  connect  different  units  that  correspond  to  the  same  component. 
Structural  links  connect  components  belonging  to  the  same  entity.  Applications  links  are 
used  for  applications  in  arbitrary  patterns  set  up  by  users. 

Based  on  above  primitives,  specifications  of  hypertext  applications  can  be 
developed.  A  specification  consists  of  a  schema  definition  and  a  set  of  instance 
definitions.  A  schema  definition  specifies  a  set  of  entity  types  and  link  types,  while 
instances  are  generated  only  if  a  set  of  rules  or  constraints  is  satisfied. 

HDM  has  another  important  primitive  called  outlines.  A  hypermedia  application 
can  be  roughly  divided  into  two  portions:  a  hyperbase  and  a  set  of  access  structures. 
What  have  been  discussed  already  are  primitives  for  defining  the  hyperbases  of  an 
application.  However,  to  facilitate  navigation,  access  structures  are  needed  to  allow  users 
to  properly  select  entry  points  of  the  application.  In  HDM,  outlines  are  provided  for  this 
purpose. 

The  HDM  primitives  provide  a  conceptual  model  for  defining  any  kind  of 
hypermedia  applications,  while  how  users  perceive  the  information  is  defined  by 
browsing  semantics. 
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HDM  Browsing  Semantics 

The  browsing  semantics,  which  is  application-related,  defines  how  a  hypertext  is 
used  and  what  information  users  can  perceive.  Since  HDM  defines  very  high  level 
concepts  of  hypermedia  design  and  does  not  aim  at  any  kinds  of  hypermedia  applications, 
it  is  impossible  for  it  to  define  lots  of  browsing  semantics  except  for  something  that  is 
common  to  all  hypertext  designs.  Thus,  by  default  HDM  only  defines  one  type  of 
browsing  semantics,  nodes-and  links.  In  other  words,  the  HDM  default  browsing 
semantics  can  only  define  units  and  links  among  units.  This  problem  is  not  that  serious 
when  dealing  with  hypermedia  applications,  because  the  browsing  semantics  for 
applications  is  normally  explicit. 

The  HDM  primitives  and  other  concepts  will  be  used  extensively  in  the  following 
chapters. 
4.1.2  QOHDM 

The  OOHDM  is  a  model-based  approach  for  hypermedia  designs.  Its  design 
process  consists  of  three  different  activities,  conceptual  design,  navigational  design,  and 
abstract  interface  design  (Schwabe,  D.,  Rossi,  G.  and  Barbosa,  S.,  1996).  OOHDM  is 
more  or  less  influenced  by  HDM,  therefore  only  major  features  of  this  methodology  are 
briefly  reviewed. 
Conceptual  Design 

OOHDM  conceptual  design  is  a  stage  to  develop  an  object-oriented  model  for  an 
application  domain.  The  result  of  this  step  is  a  schema  built  out  of  classes,  sub-classes 
and  relationships. 
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Navigational  Design 

The  navigational  design  organizes  views  for  different  users  and  different  tasks 
based  on  the  conceptual  design.  Based  on  the  conceptual  schema,  the  navigational  design 
in  OOHDM  has  two  schemas,  the  navigational  class  schema  and  the  navigational  context 
schema.  Consisting  of  navigable  objects  derived  from  the  conceptual  schema,  the 
navigational  class  schema  defines  chosen  views  over  the  application  domain.  The 
navigational  class  schema  is  like  a  redefined  conceptual  schema  for  a  particular  view. 
Based  on  the  navigational  class  schema,  the  navigational  context  schema  defines  the 
navigation  space  by  a  set  of  nodes,  links,  and  indexes  that  are  derived  from  the 
navigational  class  schema. 
Abstract  Interface  Design 

The  abstract  interface  design  defines  how  the  navigational  structure  is  perceived 
by  users  through  the  application  interface.  This  is  done  by  an  abstract  interface  model. 
The  abstract  interface  model  defines  what  interface  objects  a  user  may  perceive,  how  an 
interface  object  may  appear,  which  interface  objects  will  activate  navigation,  how 
multimedia  interface  objects  are  synchronized  and  so  on. 
4.1.3  RMM 

RMM,  a  methodology  for  designing  structured  hypermedia,  is  similar  to 
OOHDM.  There  are  seven  steps  in  the  RMM  cycle,  E-R  (Entity-Relationship)  design, 
slice  design,  navigational  design,  conversion  protocol  design,  user-interface  design,  run 
time  behavior  design,  and  construction  and  testing  (Isakowitz,  Stohr,  & 
Balasubramanian,  1995).  The  first  six  steps  are  briefly  discussed  below. 
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E-R  Design 

Instead  of  using  an  object-oriented  model,  RMM  uses  an  E-R  model  to  capture 
the  entities  and  relationships  of  the  entities.  The  model  is  presented  by  an  E-R  diagram. 
Slice  Design 

One  of  the  differences  between  OOHDM  and  RMM  is  the  slice  design.  Slices 
define  how  the  information  of  entities  is  presented  to  users  and  how  the  users  may  access 
the  information.  The  concept  of  slice  provides  a  way  to  subdivide  attributes  of  an  entity 
into  some  meaningful  groups.  For  example,  a  construction  document,  as  an  entity,  may 
contain  different  types  of  attributes,  such  as  general  information  and  contents.  Slices 
represent  different  types  of  attributes.  Thus  a  "general  information"  slice  may  have 
information  about  the  sender  and  the  receiver  of  a  document. 
Navigational  Design 

RMM  does  not  hard  code  any  links  between  instances  of  entities,  therefore  the 
navigational  paths  are  specified  in  generic  terms  and  links  are  generated  at  runtime.  In 
RMM,  navigational  design  starts  at  the  entity  level.  The  relationship  between  two  entities 
is  defined  by  associative  relationships.  The  structural  relationships  in  an  entity  define 
relationships  among  slices  of  the  entities. 

RMM  uses  three  types  of  navigational  approaches,  conditional  indexes, 
conditional  guided  tours  and  conditional  indexed  guided  tours. 
Conversion  Protocol  Design 

This  step  uses  a  set  of  rules  to  transform  each  element  of  the  E-R  diagram  into  the 
target  platform. 
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User  Interface  Design 

This  step  is  similar  to  the  user  interface  design  in  the  OOHDM.  It  involves  the 
design  of  layout  of  information  elements  and  other  interface  elements  such  as  buttons. 
Run  Time  Behavior  Design 

This  step  decides  whether  the  contents  of  nodes  and  links  are  built  during 
application  development  or  dynamically  computed  on  demand  at  runtime. 
4.1.4  Summary  of  Design  Methodologies 

All  three  methodologies  adopt  a  three-schema  strategy.  One  schema  defines  the 
hyperbase  of  applications  no  matter  what  terms  are  used.  HDM  uses  "primitives", 
OOHDM  uses  object-oriented  models  and  RMM  uses  E-R  models.  A  second  schema 
deals  with  the  navigation  of  the  hyperbase  defined  by  the  first  schema  such  as  the 
browsing  semantics  of  HDM  and  the  navigational  design  of  OOHDM  and  RMM.  A  third 
schema  focuses  on  how  information  is  perceived  by  users. 

This  research  will  also  adopt  the  three-schema  strategy  including  a  conceptual 
schema,  a  navigational  schema  and  a  presentation  schema. 

4.2  Malleability  Considerations  for  the  System  Design 

As  mentioned  in  Chapter  2,  a  "malleable  frame"  system  will  support  two  types  of 
malleability,  namely  vertical  malleability  and  horizontal  malleability.  The  vertical 
malleability  deals  with  the  process  of  document  processing  and  the  horizontal 
malleability  deals  with  processing  a  document  for  a  particular  step  such  as  from  a 
Request  for  Change  Order  Proposal  to  a  Change  Order  Proposal.  This  research  will  focus 
mainly  on  horizontal  malleability. 
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The  major  issues  that  need  to  be  considered  while  designing  a  "malleable  frame" 
system  are  document  preparation  and  interpretation,  information  binding,  user 
interactions,  and  document  workflow  process. 

4.2.1  Document  Preparation  and  Interpretation 

Malleability  reflects  in  document  preparation  and  interpretation  in  such  a  way  that 
a  document  is  prepared  and  interpreted  by  a  standard  or  shared  document  schema. 
Chapter  3  shows  the  methodology  of  developing  such  a  document  schema  with  an 
example  of  a  Request  for  Change  Order  Proposal.  Different  systems  share  the  semantic 
information  of  documents  so  that  they  can  interpret  documents  exactly  the  same  way. 

4.2.2  User  Interactions 

Human-machine  interaction  is  a  two-direction  interaction.  It  is  widely  agreed  that 
when  people  use  a  device  or  think  about  a  system  they  do  so  with  the  aid  of  a  mental 
model  that  characterizes  the  system.  The  degree  to  which  the  user's  mental  model 
matches  the  conceptual  model  will  determine  the  user's  ability  to  successfully  operate  the 
device.  Several  researchers  have  found  that  providing  learners  with  a  clear  conceptual 
model  along  with  operating  instructions  enhanced  learning  relative  to  conditions  in  which 
only  procedural  instructions  were  provided  (Mark,  Warm,  &  Huston  1987).  This  research 
tries  to  provide  users  with  information  indexes  to  help  them  establish  a  mental  model  of  a 
document  and  related  local  information  although  there  may  be  other  ways. 

Furthermore,  capturing  user  interactions  effectively  is  a  way  to  allow  a  user  to 
take  advantage  of  malleability.  Since  the  focus  of  this  research  is  to  allow  a  user  to 
manipulate  document  elements  and  related  local  information  simultaneously,  research 
interests  will  be  on  providing  the  user  with  tools,  indexes  in  this  case,  to  manipulate  these 
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two  types  of  information.  The  most  important  one  is  the  index  showing  both  document 
elements  and  related  local  information  so  that  a  user  can  interacted  with  the  two 
information  sources  simultaneously  and  tailor  the  display  of  information  according  to 
his/her  needs. 
4.2.3  Information  Binding 

One  of  the  key  issues  to  achieve  malleability  is  that  document  elements, 
especially  those  about  a  building  component  or  a  construction  activity,  are  properly 
indexed  so  that  when  a  system  receives  a  document  about  "slab  on  grade"  the  system  will 
be  able  to  retrieve  local  information  about  "slab  on  grade"  exactly.  Information  binding  is 
different  from  the  document  interpretation  discussed  above,  since  it  deals  mainly  with 
how  to  bind  one  object  with  other  related  objects  in  another  system.  Therefore,  binding 
the  two  types  of  information,  document  information  and  related  local  information,  is  the 
key  issue. 

As  discussed  previously,  an  information  index  is  what  makes  the  binding 
possible.  Such  an  information  index  has  to  either  be  standardized  or  shared  by 
collaborating  systems.  Fortunately,  there  are  many  research  studies  on  classifying 
construction  information  and  the  standardization  of  classifications.  One  of  the  standards 
is  the  CSI  Masterformat.  Many  applications  have  already  used  Masterformat  to  index 
construction  information.  So  finding  a  proper  index  system  should  not  be  a  problem.  This 
chapter  will  review  some  major  construction  information  classification  systems  and 
discuss  how  to  use  them  for  this  research. 
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4.2.4  Document  Workflow 

Since  this  topic  is  related  to  the  vertical  malleability,  it  is  not  a  major  focus  of  this 
research.  This  research  will  only  discuss  some  basic  ideas  on  how  to  incorporate  process 
information  into  the  "malleable  frame"  system. 

4.3  A  "Malleable  Frame"  System 

This  section  will  discuss  the  integration  of  malleability  considerations  with  the 
system  architecture  of  a  "malleable  frame"  system.  The  system  architecture  will  be 
discussed  first.  Then  each  of  schemas  will  be  studied  in  detail. 
4.3.1  System  Architecture 

Figure  4. 1  shows  the  system  architecture  of  a  "malleable  frame"  system,  which  is 
used  by  the  implementation  of  a  prototype  system,  Kaleidoscope  (Zhu,  1999). 


Functional  Module  I 


Functional  Module  II 


Presentation  Schema 


Document  Templates 


Navigational  Schema 


Conceptual  Schema 


Figure  4.1  The  system  architecture  of  Kaleidoscope 
Taking  advantage  of  XML  technology,  the  conceptual  schema  is  responsible  for 
the  entire  hyperbase  of  applications.  Such  responsibilities  include  generating  and 
maintaining  an  internal  generic  representation  of  construction  documents,  tagging  each 
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document  information  elements  and  local  information  elements,  and  binding  document 
information  elements  and  related  local  information  elements. 

Two  functional  modules  are  built  on  the  top  of  the  conceptual  schema.  The 
functional  module  I,  which  includes  the  navigational  schema  and  the  presentation 
schema,  is  for  reviewing  and  processing  a  document.  The  functional  module  II  is  for 
preparing  construction  documents. 

Based  on  the  information  provided  by  the  conceptual  schema,  the  navigational 
schema  is  used  for  dynamically  generating  information  indexes  for  users. 

The  presentational  schema  deals  with  presentation  issues. 

The  functional  module  II  has  a  series  of  construction  document  templates  and  the 
conceptual  supplies  standard  tags  for  particular  elements  of  a  document.  This  is  how  to 
make  a  document  understandable  by  another  machine  that  shares  the  same  tags. 

This  research  will  implement  the  conceptual  schema  and  the  functional  module 
one,  however,  theoretical  discussions  on  the  functional  module  two  will  be  given  as  well. 
4.3.2  The  Conceptual  Schema 

The  conceptual  schema  defines  types  of  information  and  relationships  between 
the  types.  To  be  completely  consistent  with  the  document  design  in  chapter  three,  the 
conceptual  schema  also  consists  of  three  general  types  of  information,  the  document 
information,  the  project  information  and  the  document  content.  Figure  4.2  shows  the 
structure  of  the  conceptual  schema. 

For  details  of  the  conceptual  schema,  please  refer  to  "Implementation  of  Dynamic 
Hypermedia  Generation  for  Construction  Document  Processing"  (Zhu,  1999).  "docUnit" 
refers  to  the  information  units  from  a  document  such  as  project  number,  sender,  recipient. 
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checklist  and  so  on.  A  "docUnit"  is  the  actual  information  container.  Similarly, 
information  from  local  system  is  structured  as  well.  Following  the  hypermedia  design 
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Source:  Zhu,  1999 


Figure  4.2  The  conceptual  schema 
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methodology  discussed  previously,  local  nodes  stand  for  entities,  below  which  local 
information  types  such  as  scheduling  and  estimating  stand  for  components,  and  the 
attributes  of  the  components  are  the  "localUnits". 

4.3.3  The  Navigational  Schema 

Three  kinds  of  index  structures  will  be  provided  for  users  to  navigate  through  the 
hyperbase  defined  by  the  conceptual  schema,  i.e.  the  document  index,  the  single  index 
and  the  mixed  index.  The  document  index  is  for  manipulating  the  document  only.  This 
index  allows  a  user  to  tailor  the  document  presentation.  The  single  index  lets  a  user  see 
one  piece  of  information  a  time.  For  example,  if  the  user  only  wants  to  see  the  early  start 
time  of  an  activity,  this  index  will  allow  him  to  do  that.  However,  the  most  important 
index  is  the  mix  index  that  allows  a  user  to  tailor  both  document  information  and  local 
information  simultaneously  and  present  the  customized  document  as  one  single 
document.  Figure  4.3  shows  the  generation  of  the  three  indexes. 

Figures  4.4,  4.5  and  4.6  show  examples  of  the  three  indexes  implemented  by 
Kaleidoscope.  Please  refer  to  "Implementation  of  Dynamic  Hypermedia  Generation  of 
Construction  Document  Processing"  (Zhu,  1999)  for  detailed  specifications  of  the  index 
structures. 

4.3.4  The  Presentation  Schema 

Each  of  the  above  indexes  is  corresponding  to  a  display  template.  A  display 
template  defines  the  type  and  the  format  of  information  to  be  displayed.  Please  refer  to 
"Implementation  of  Dynamic  Hypermedia  Generation  of  Construction  Document 
Processing"  (Zhu,  1999)  for  detailed  specifications  of  the  three  corresponding  display 
templates. 
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Figure  4.3  The  generation  of  the  three  indexes 
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Figure  4.4  A  document  index 
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Figure  4.5  A  single  index 
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Figure  4.6  A  mixed  index 
Figure  4.7  explains  the  generation  of  a  presentation.  Each  entry  of  an  index  has  a 
unique  tag  and  two  states  standing  for  "checked"  and  "not  checked".  The  tags  used  in  the 
navigational  schema  are  also  used  for  the  presentation  schema.  Each  tag  in  the 
presentation  schema  is  associated  with  a  set  of  definitions  about  how  information  should 
be  displayed,  such  as  font,  font  size,  style  and  relative  positions.  Such  template  is  very 
similar  to  a  style  sheet.  Therefore,  if  an  entry  is  checked,  the  corresponding  tag  will  be 
sent  over  to  the  corresponding  template.  Based  on  tag  match,  the  system  will  be  able  to 
understand  what  information  to  display  and  what  format  will  be  used  for  that  particular 
information. 
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Figure  4.7  A  two-step  procedure  for  display 
4.4  Construction  Information  Classification  Systems  (CICS) 

Figure  4.2  illustrates  that  there  is  a  relationship  between  a  "docUnit"  and 
"localUnit."  The  relationship  is  crucial  for  malleability.  To  establish  and  maintain  such  a 
relationship  an  information  classification  system  is  needed  and  shared  by  different 
system.  Existing  classification  systems  such  as  the  CSI  Masterformat  can  be  used  to 
serve  this  purpose. 

4.4.1  A  Brief  History  of  Related  Research  Studies 

Although  the  effort  of  classifying  construction  information  has  been  on-going 
since  even  before  World  War  II,  such  work  started  receiving  enough  attention  only  after 
the  war  in  order  to  coordinate  the  reconstruction  of  so  many  different  countries  in 
Europe.  Since  then,  standardization  became  a  very  important  issue  both  in  Europe  and 
the  United  States  (Brandon,  &  Betts,  1995).  Table  4.1  below  shows  some  of  the  major 
events  of  this  effort. 
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Table  4.1  Major  events  of  construction  information  classification 


Time 

Sponsor 

Event 

1920 

The  American  Institute  of 
Architecture  (AIA) 

Publishing  the  first  edition  of  "Standard  Filing  System  and 
Alphabetical  Index",  the  first  construction  material 
classification 

1947 

The  Joint  Working 
Committee  for  Building 
Problems  in  Sweden 

Samarbetskommiten  for  Byggnadsfragor  (SfB)  for 
classifying  construction  information 

1950 

The  Joint  Working 
Committee  for  Building 
Problems  in  Sweden 

Construction  Index  /  Samarbetskommiten  for 
Byggnadsfragor  (CI/SfB)  for  classifying  construction 
information 

1963 

The  Construction 
Specification  Institute  (CSl) 

CSl  format  for  building  construction  with  16  divisions 

1972 

Several  organizations 
including  CSl  and 
Construction  Specification 
Canada  (CSC) 

Publishing  the  Uniform  Construction  Index  (UCI). 

1975 

The  General  Services 
Administration  (GSA) 

The  "Uniformat"  with  a  12  major  divisions. 

1976 

The  Institution  of  Civil 
Engineers 

The  Civil  Engineering  Standard  Method  of  Measurement 
(CESMM)  system  for  quantity  survey 

1978 

CSl  and  CSC 

Publishing  the  first  edition  of  Masterformat  system 

1996 

The  United  Classification  for 
the  Construction  Industry 
(UUCl) 

An  updated  Cl/SfB 

Unknown 

The  International 
Organization  for 
Standardization  (ISO) 

A  new  classification  system  for  the  construction  industry 

At  present,  the  CSl  Masterformat,  the  SfB  system,  the  CI/SfB  system,  the 
CESMM  system  and  the  ISO  system  are  the  most  popular  classification  system  (loannou, 
&.  Liu,  1993,  Kang,  &  Paulson,  1997).  Table  4.2  shows  a  brief  comparison  those  major 
systems. 
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Table  4.2  Comparison  of  existing  construction  information  classiflcation  systems 


Masterformat 

SfB 

CI/SfB 

CESMM 

ISO 

Structure 

Hierarchy 

Facet 

Facet 

Hierarchy 

Facet 

Notation 

Decimal 
system 

Mixed  system 

Mixed  system 

Mixed  system 

Under 

development 

Classes 

16  Division 

Three  facets 

Five  facets 

26  Division 

Eight  facets 

Scope  of 
Classiflcation 

Operation 

Element  and 
operation 

Facility, 
element,  and 
operation 

Operation 

Facility,  space, 
element,  and 
operation 

Application  of 
system 

Not  applicable 
to  facility  and 
element 
classifications 
Need  more 
detailed  items 
for  civil  works 

Not  applicable 
to  facility 
classification 
Based  on  the 
architectural 
work 

Not  applicable 
to  element 
classification 
for  civil  works 
Excellent  for 
architectural 
works 

Not  applicable 
to  facility  and 
element 
classifications 
Excellent  for 
operation  items 
for  civil  works 

Under 

development 

Source:  Kang,  &  Paulson,  1997 


Among  those  classification  systems,  the  CSI  Masterforrnat  is  usually  the  one 
selected  by  researchers  in  the  North  America  because  it  is  developed  in  the  North 
America  and  widely  accepted  by  the  U.S.  and  the  Canadian  construction  industry  as  a 
standard  (Masterformat  -  manual  of  practice,  1983,  loannou,  &  Liu,  1993,  Shrive,  1995, 
Mincks,  &  Johnston,  1998,  Kang,  &  Paulson,  1998). 
4.4.2  CSI  Masterformat 

One  of  the  principles  of  CSI  is  to  establish  a  standard  location  for  specific 
information  and  to  state  that  information  only  in  that  location  (Masterformat  -  manual  of 
practice,  1983).  The  CSI  Masterformat  is  designed  to  uniquely  locate  information  for  a 
specific  building  item  or  activity  and  only,  so  there  is  always  a  one-to-one  relationship 
between  the  CSI  Master  Format  classification  and  building  information.  Such  a 
classification  greatly  helps  construction  professional  to  locate  particular  information 
manually  or  electronically. 
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Sixteen  Division  Specification  Format 

The  sixteen  divisions  of  the  CSI  Masterformat  are  fixed  in  both  number  and  title 
regardless  project  types.  Under  each  division,  there  are  different  sections  covering  one 
portion  of  the  project  requirements.  A  section  grouping  together  related  items  defines 
particular  materials  or  products  and  their  installations,  or  particular  administrative  or 
procedural  requirements  (Masterformat  -  manual  of  practice,  1983).  An  example  of  the 
relationship  between  a  division  and  its  sections  is  shown  by  Figure  4.3. 

Division  3  Concrete 

033 10  Structural  Concrete 

033 11  Footings 

03312  Foundation  Wall 

03320  Concrete  Topping 

Figure  4.3  An  example  of  the  relationship  between  a  division  and  its  sections 
Level  of  Details 

The  CSI  Masterformat  identifies  three  levels  of  details,  namely  broadscope, 
mediumscope  and  narrowscope.  Broadscope  titles  are  for  broad  categories  of  work  and 
provide  the  widest  latitude  in  describing  a  unit  of  work.  Mediumscope  title  cover  unites 
of  work  of  more  limited  scope.  Narrowscope  titles  are  used  to  cover  extremely  limited 
and  very  specific  elements  of  work  (Masterformat  -  manual  of  practice,  1983). 
Standardized  Numbers  and  Titles 

The  CSI  Masterformat  suggests  a  five-digit  numbering  system  for  the  broadscope 
and  mediumscope  titles  as  shown  in  Figure  4. 1 .  The  first  two  digits  refer  to  a  division 
and  the  rest  refer  to  different  sections.  Therefore,  the  number  "0331 1"  means  "Division 
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3"  for  "03000",  "Cast-in-Place  Concrete"  for  "03300",  "Structural  Concrete"  for  "03310" 
and  "Footings"  for  "03311". 

In  the  above  example,  "03300"  defines  a  broadscope,  "03310"  defines  a 
mediumscope  and  "033 11"  defines  a  narrowscope.  Normally,  Masterformat  only  defines 
up  to  "03310"  while  more  detailed  information  such  as  "033 11"  needs  to  be  added 
according  to  a  particular  project. 
4.4.3  Using  CSI  Masterformat 

The  CSI  Masterformat  has  been  widely  used  for  classifying  construction 
information  in  different  situations.  It  is  used  for  estimating  and  accounting  purposes 
(Bertolini,  &  Syal,  1998),  for  classifying  emerging  construction  technologies  (loannou, 
&  Liu,  1993),  for  integrating  safety  and  health  performance  into  construction  CPM 
(Kartam,  1997),  for  classifying  construction  project  information  (Shahld,  &  Froese, 
1998)  and  many  other  applications. 

Following  are  three  typical  examples  that  use  the  CSI  Masterformat  to  classifying 
construction  information. 

The  Advanced  Construction  Technology  System  (ACTS) 

The  Advanced  Construction  Technology  System  (ACTS)  is  a  computer  database 
for  classification,  documentation,  storage  and  retrieval  of  information  about  emerging 
construction  technology  (loannou,  &  Liu,  1993).  Technologies  in  the  ACTS  database  are 
classified  according  to  the  CSI  Masterformat  so  that  each  technology  in  the  ACTS 
database  belongs  to  exactly  one  broadscope  or  mediumscope  section. 

The  documentation  of  a  technology  is  stored  in  a  file  in  the  ACTS  subdirectory 
whose  filename  has  the  form  ACTccccc.nim.  The  string  "ccccc"  represents  the  five-digit 
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code  of  the  corresponding  broadscope  or  mediumscope  section.  The  extension  "nnn"  is 
an  indexing  number  beginning  with  "001"  for  the  first  technology  of  the  corresponding 
CSI  number.  Therefore,  if  a  file  is  named  as  "ACT033 10.001",  you  know  that  this  file  is 
the  first  technology  in  the  category  of  "Structural  Concrete". 

To  search  and  retrieve  a  file,  the  ACTs  provides  a  keyword  mode  and  a  CSI 
mode.  For  the  CSI  mode,  a  user  can  first  access  to  the  Broadscope  section  and  then  the 
mediumscope  section.  Since  each  file  name  is  associate  with  a  broadscope  or 
mediumscope  title,  all  technology  associated  with  a  broadscope  or  mediumscope  title 
will  then  be  displayed  under  the  corresponding  section. 
The  IKIS-Safetv 

The  IKIS-Safety,  Integrated  Knowledge  Intensive  System  for  Construction  Safety 
and  Health  Performance  Control,  is  a  proactive  safety  system  that  integrates  safety  and 
health  issues  into  all  phases  of  a  construction  project  from  design,  construction  to 
maintenance  (Kartam,  1997). 

The  IKIS-Safety  uses  CSI  Masterformat  as  a  common  data  set  between  a  safety 
record  database  and  a  construction  schedule.  The  system  first  classifies  safety  records  by 
using  CSI  Masterformat  and  other  mechanism  such  as  keywords  and  24  OSHA 
(Occupational  Safety  and  Health  Administration)  subparts.  Then  when  checking  safety 
records  for  a  certain  activity,  a  temporary  file  with  an  activity  ID,  a  CSI  activity  code  and 
a  comment  field  is  generated.  This  temporary  file  is  passed  to  the  database  management 
system.  Since  safety  records  are  stored  according  to  CSI's  broad,  medium  and  narrow 
scope  approach,  the  corresponding  safety  records  can  then  be  matched  with  the  activity. 


93 

In  this  system,  there  are  two  important  things  that  need  to  be  noticed.  First, 
information  is  classified  up  to  the  narrowscope  level.  Second,  each  activity  in  scheduling 
is  also  assigned  a  CSI  code  besides  its  activity  ID. 
The  Project  Management  Information  Control  System  (PMICS) 

The  PMISC  is  designed  for  construction  professionals  to  enter  information  for  a 
wide  variety  of  project  events,  cross-reference  the  various  bodies  of  information,  and  use 
the  information  to  monitor  and  control  various  aspects  of  a  construction  project  (Shahld, 
&  Froese,  1998).  The  system  incorporates  the  CSI  Masterformat  into  its  conceptual 
schema  in  order  to  classify  information.  However,  it  is  recognized  that  the  CSI 
Masterformat  is  not  precise  enough  to  use  for  differentiating  all  of  the  individual  items  in 
an  estimating.  Thus  the  specification  sections  are  related  to  a  more  detailed  work 
breakdown  structure  (WBS)  classification  scheme  adopted  from  the  American  Society  of 
Professional  Estimators  (ASPE)  (Shahld,  &  Froese,  1998). 

The  system  is  implemented  by  relational  database  technology.  In  total  25  tables 
are  used.  Among  them  a  table  called  WBS  Item  lists  all  project  activities  is  keyed  by 
using  WBS  ID  and  Specification  ID  (Shahld,  &  Froese,  1998).  Thus  each  activity  of  a 
project  has  a  one-to-one  relationship  with  the  combination  of  WBS  ID  and  Specification 
ID.  This  is  how  an  individual  activity  is  managed  by  PMICS. 
4.4.4  The  Use  of  the  CSI  Masterformat  for  Malleability 

The  previous  discussion  shows  that  either  the  CSI  Masterformat  alone,  i.e.  ACTS 
and  IKIS-Safety  or  the  CSI  Masterfomat  with  some  extension  i.e.  PMICS  can  very  well 
classify  construction  information  at  a  detailed  level.  For  the  purpose  of  this  research  if 
such  a  classification  system  can  be  shared  by  all  project  participants,  a  building  item  or  a 
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construction  activity  described  by  one  system  can  be  interpreted  correctly  by  another 
system.  Since  it  is  not  the  focus  of  this  research  to  further  investigate  this  issue,  it  is 
assumed  that  the  existing  classification  systems  such  as  the  CSI  Masterformat  can  be 
used  for  the  purpose  of  this  research. 

4.5  Summary 

A  "malleable  frame"  system  is  a  hypermedia  system.  Major  hypermedia  design 
methodologies  such  as  HDM,  OOHDM  and  RMM  have  been  widely  used.  Based  on 
these  methodologies,  this  research  adopts  a  three-schema  strategy,  i.e.  a  conceptual 
schema,  a  navigational  schema  and  a  presentation  schema.  The  conceptual  schema  is  for 
maintaining  a  hyperbase  that  consists  of  document  information  elements  and  local 
information  elements.  The  navigational  schema  defines  ways  that  users  can  access  to  the 
hyperbase.  The  presentation  schema  is  for  presentations  of  documents  and  customized 
information. 

Malleability  is  basically  reflected  in  the  conceptual  schema  and  the  navigational 
schema.  The  conceptual  schema  is  defined  according  to  design  of  the  "malleable  frame" 
and  each  "docUnit"  is  associated  with  a  unique  tag.  In  this  way,  if  such  tags  are  shared  by 
different  system,  those  systems  will  be  able  to  interpret  a  document  in  the  same  way. 
Another  reflection  of  malleability  in  the  conceptual  schema  is  that  document  information 
elements  and  related  local  information  are  bonded  via  a  shared  or  standardized 
information  index  system.  Therefore  information  from  two  different  sources  forms  one 
logical  hyperbase  that  is  represented  as  the  conceptual  schema.  Once  a  hyperbase  is 
formed,  tools  are  provided  for  users  to  manipulate  the  hyperbase  and  tailor  information 
presentations  in  terms  of  content  and  format  according  to  their  needs.  Such  capabilities 
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are  the  most  direct  reflection  of  malleability.  The  navigational  schema,  providing  three 
types  of  indexes,  furnishes  users  with  such  capabilities. 

In  order  to  bind  document  information  elements  with  related  local  information,  a 
shared  or  standardized  information  index  system  must  be  available.  Many  research 
studies  (loannou,  &  Liu,  1993,  Kartam,  1997,  Bertolini,  &  Syal,  1998,  Shahld,  &  Froese, 
1998)  have  shown  that  the  CSI  Masterformat  is  an  ideal  tool,  therefore  this  research 
assumes  that  the  CSI  Masterformat  can  be  used  as  the  information  index  system. 


CHAPTER  5 
SYSTEM  IMPLEMENTATION 

The  implementation  of  a  prototype  "malleable  frame"  system,  called 
Kaleidoscope,  is  accomplished  by  using  XML  technology  and  Java  programming 
language. 

5.1  Overview  of  Implementation  Technology 

5.1.1  Document  Representation  and  the  Document  Object  Model  (DOM) 

No  matter  what  it  is,  a  "valid"  document  or  a  well-formed  document,  an  XML 
document  is  represented  by  a  tree  structure.  The  tree  structure  is  used  as  a  logical 
structure  of  XML  documents.  A  sample  document  segment  is  shown  in  Figure  5.1,  and 
the  corresponding  tree  structure  is  shown  in  Figure  5.2. 

Based  on  such  a  tree  structure,  the  Document  Object  Model  (DOM)  Application 
Programming  Interface  (API)  provides  tools  to  build  documents,  navigate  their  structure, 
and  manipulate  their  elements  and  content.  The  DOM  has  a  DOM  (Core)  level  1  for 
dealing  with  XML  documents  and  a  DOM  (HTML)  level  I  for  handling  HTML 
documents.  Here  we  only  use  the  DOM  (Core)  level  1  API. 

According  to  the  DOM  (Core)  level  1  API,  there  are  13  node  types  in  total 
(Document  Object  Model  Specification,  1999,  Walsh,  1997).  They  are  Document, 
DocumentFragment,  DocumentType,  EntityReference,  Element,  Attr, 
Processinglnstruction,  Comment,  Text,  CDATASection,  Entity,  and  Notation.  The  COM 
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core  API  provides  various  kinds  of  classes  and  methods  for  manipulating  each  type  of 
nodes.  Please  refer  to  http://www.w3c.org/  for  a  list  of  COM  (Core)  Level  1  API  and 
details  about  DOM. 
5.1.2  XML  Parsers 

There  are  several  parsers  available  for  developers.  Some  parsers,  such  as  the  IBM 
parser  (XML  for  Java,  1997)  and  the  Microsoft  parser  (Paoli,  Schach,  Lovett,  Layman,  & 
Cseri,  1997)  not  only  do  document  validation  but  also  generate  the  parse  tree  to  allow 
DOM  API  to  manipulate  the  document.  Some  other  parsers  do  document  validation  only. 
In  this  project,  the  IBM  parser  is  used. 


<change_order> 

<sender_info> 

<name>CISE</name> 

<address>University  of  Florida</address> 
</sender_info> 
<receiver_info> 

<name>Clark  Construction</name> 

<address>3476  NW,  Gainesville</address> 
</receiver  info> 


Figure  5.1  A  sample  of  document  segment 
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name 

address 

name 

address 

CIS 


University  of 
Florida 


t 

Clark 

Constructio 


3476  NW, 
Gainesville 


Figure  5.2  the  tree  structure  of  the  document  segment 
5.1.3  XML  and  Web  Database  Integration 

Since  XML  is  merely  a  meta-language  for  defining  open  data  format,  it  can  be 
used  to  define  other  languages  and  applications.  One  of  such  applications  is  the  Web 
distributed  data  exchange  (WDDX)  technology  (ColdFusion  White  Paper,  1997,  Porta, 
1998,  Allaire,  1998).  Created  by  Allaire,  WDDX  tries  to  solve  key  problems  in 
exchanging  data  between  Web  applications  by  using  some  standard  data  format.  As  of 
this  writing,  WDDX  is  not  a  formal  standard  yet  and  it  has  not  been  submitted  to  the 
W3C  or  any  other  standards  body.  However,  WDDX  is  freely  available  for  use  and 
redistribution,  and  is  based  on  open,  standards-based  technologies  such  as  XML  1.0. 

The  WDDX  has  three  basic  terms,  Packet,  Serializing  and  Deserializing  (Porta, 
1998,  Allaire,  1998).  A  WDDX  Packet  is  any  chunk  of  data  that  has  been  stored  in  the 
WDDX  format.  Serializing  is  the  process  of  taking  some  pieces  of  data  and  converting  it 
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into  a  WDDX  Packet.  Deserializing  is  the  opposite  process  of  Serializing,  which  takes 
the  data  out  of  an  existing  WDDX  Packet. 

The  idea  of  this  technology  is  to  turn  any  kind  of  data,  a  simple  integer  or  a 
complex  structure,  into  a  chunk  of  ASCII  text.  That  chunk  of  text  is  stored  in  the  WDDX 
format.  When  the  data  is  needed  again,  it  is  then  translated  back  into  the  format  as  it  was. 
Since  the  WDDX  data  format  uses  XML,  the  chunk  of  data  is  thus  portable.  For  example, 
an  application  uses  WDDX  to  take  a  complex  array  in  ColdFusion,  serialize  it  into  XML, 
send  it  to  other  requesting  applications,  and  then  deserialize  from  XML  into  an  object 
that  is  native  to  the  applications. 

As  a  XML  application,  WDDX  provides  a  new  way  to  allow  different 
programming  environments  to  share  data.  That  is  one  of  the  major  features  that  promise 
WDDX  a  good  future. 

Besides  ColdFusion  who  initiates  the  efforts  of  integrated  XML  into  database 
systems,  other  database  vendors,  such  as  Oracle,  Informix,  Object  Design  and  POET,  are 
starting  moving  towards  this  direction  (Mendel,  1999). 
5.1.4  Java  Programming  Language 

Java  programming  language  is  designed  for  intemetAVeb  applications.  It  provides 
a  rich  set  of  classes  dealing  with  intenetAVeb  programming,  user  interface  programming, 
concurrent  programming  and  many  other  applications.  These  features  make  Java 
programming  language  an  ideal  tool  for  the  implementation  of  Kaleidoscope. 

5.2  Implementation  Strategies 

Following  the  design  details,  the  implementation  of  Kaleidoscope  is  composed  of 
three  modules.  Module  one  focuses  on  generating  and  maintaining  the  conceptual  schema 
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by  using  XML  technology  and  the  IBM  parser.  An  API  (Application  Programming 
Interfaces),  implemented  by  class  "myDocument",  is  provided  for  manipulating  the 
conceptual  schema.  Module  two  is  for  implementing  the  navigational  schema  based  on 
the  services  provided  by  module  one.  Module  three  is  the  implementation  of  the 
presentation  schema. 

Figure  5.3  shows  the  flow  of  document  information  within  the  system. 

The  system  starts  reading  in  a  construction  document  that  is  in  XML  format.  A 
XML  parser  will  parse  the  document  first.  After  parsing,  the  system  then  understands 
what  type  of  document  it  is  and  what  building  components  are  mentioned  in  the 
document.  The  system  handler  will  handle  tag  matching  so  that  tags  of  a  default  view 
will  be  read  in  and  corresponding  document  information  will  be  sent  to  the  corresponding 
template  for  display.  The  indexes  are  generated  by  the  document  handler  according  to 
different  documents.  Users  may  interact  with  the  indexes  to  change  default  views  to 
particular  documents. 

The  actual  implementation  is  composed  of  three  modules.  The  XML  parser  and 
the  document  handler  are  implemented  as  module  one.  Module  two  includes  the  indexes 
and  the  default  view.  Module  three  deals  with  the  templates  and  presentation. 

Appendix  B  includes  some  screen  shots  of  Kaleidoscope.  For  details  of  the 
implementation  of  Kaleidoscope,  please  refer  to  "Implementation  of  Dynamic 
Hypermedia  Generation  for  Construction  Document  Processing"  (Zhu,  1999). 
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Figure  5.3  The  flow  of  document  information  within  the  system 
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5.3  Assumptions  and  Limitations 

5.3.1  Assumptions 

The  Kaleidoscope  project  is  based  on  several  assumptions  that  are  related  to  the 
two  inputs,  namely  the  construction  documents  and  the  associated  local  information. 

•  The  project  uses  XML  to  represent  structured  construction  documents.  Since  such 
practice  has  not  been  a  standard  approach  yet,  assumptions  about  XML  tags  and 
document  structures  are  needed.  For  instance,  as  shown  in  Figure  5.4,  the  project  may 
use  following  XML  tags  denoting  some  nodes  in  a  construction  document. 

<documentType  docName="changeRequest"  id="CH-123"> 

Request  for  Change  Order  Proposal 

</documentType> 

<project  projectNumber="l"> 

<name>Gator  Hospital</name> 
</project> 

Figure  5.4  An  example  of  a  construction  document  in  XML  format 
In  the  above  example,  the  node  names,  such  as  "documentType",  "project"  and 
"name",  and  attribute  names,  such  as  "docName"  and  "projectNumber",  should  be 
part  of  construction  document  vocabulary.  This  vocabulary  has  to  be  an  industrial 
standard  or  at  least  shared  by  systems.  Currently,  such  vocabulary  does  not  exist.  And 
there  is  no  industrial  standard.  Therefore  in  the  project  we  need  to  assume  our  own 
vocabulary. 

•  One  of  the  major  features  of  Kaleidoscope  is  its  ability  to  combine  a  document 
information  element  with  related  local  information.  As  discussed,  such  capability 
relies  on  a  information  index  system  that  is  shared  by  different  systems.  Without 
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giving  details,  this  research  assumes  that  the  CSI  Masterformat  can  be  used  for  this 
purpose. 

•  Another  input  of  the  system  is  information  from  the  local  system.  Normally,  the 
information  is  stored  in  various  kinds  of  databases.  In  order  to  make  Kaleidoscope 
portable,  this  research  assumes  to  use  a  new  technology  called  WDDX  (Web 
Distributed  Data  eXchange).  The  records  retrieved  from  local  database  are  assumed 
in  WDDX  format. 

5.3.2  System  Limitations 

Major  limitations  of  Kaleidoscope  are  listed  as  following. 

•  Kaleidoscope  can  only  deal  with  a  small  hyperbase  and  does  not  allow  users  to  go 
beyond  that  small  byperbase  composed  of  a  document  and  related  local  information. 
In  real  applications,  a  user  may  need  more  local  information  than  what  is  currently 
provided  by  the  Kaleidoscope.  That  is  to  say  Kaleidoscope  needs  to  provide  gateways 
to  other  systems,  scheduling  systems,  estimating  systems  and  so  on.  Otherwise, 
Kaleidoscope  may  eventually  confine  a  user's  capability  instead  of  improving  it. 

•  Kaleidoscope  currently  only  deals  with  one  document  at  a  time.  There  are  cases  that  a 
user  may  need  to  open  two  or  more  documents  simultaneously.  Such  situation  has  not 
been  studied  carefully  yet. 

•  Currently,  Kaleidoscope  only  allows  one  type  of  document  unit  to  be  active  and 
searchable  for  related  local  information  at  one  time.  An  extreme  case  will  be  that  all 
units  are  active.  Further  studies  are  needed  to  optimize  such  situation. 
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•  Kaleidoscope  currently  can  only  deal  with  simple  data  structures,  such  as  strings. 
More  complex  data  structures,  such  as  data  structures  for  video,  audio,  CAD,  3D  and 
so  on,  cannot  be  handled  by  the  system  at  present. 

•  Vertical  malleability  is  an  important  part  of  malleability.  This  research  only  focuses 
on  horizontal  malleability,  leaving  vertical  malleability  only  to  a  little  theoretical 
analysis.  Further  studies  are  needed  on  this  topic. 

5.4  Summary 

This  chapter  summarizes  the  implementation  of  Kaleidoscope,  a  prototype 
"malleable  frame"  System.  Details  of  the  implementation  and  assumptions  and 
limitations  of  Kaleidoscope  are  discussed  in  "Implementation  of  Dynamic  Hypermedia 
Generation  for  Construction  Document  Processing"  (Zhu,  1999). 


CHAPTER  6 
HYPOTHESIS  TESTING 

6.1  Introduction 

Previous  discussions  show  that  it  is  technically  feasible  to  build  a  "malleable 
frame"  system.  This  chapter  will  answer  a  basic  question,  which  is  "Is  the  'malleable 
frame'  system  a  better  system?  " 

To  answer  the  question,  two  types  of  test  systems  are  set  up.  One  is  called  a 
standard  system  and  simulates  a  system  that  cannot  automatically  place  a  received 
document  and  related  local  information  into  one  screen.  The  other,  called  a  "malleable 
frame"  system,  simulates  a  system  that  can  automatically  put  a  construction  document 
and  related  local  information  into  one  screen,  which  implies  that  the  local  information 
system  understands  what  the  received  document  is  and  what  to  do  with  it.  Such 
capabilities  are  basic  features  of  a  "malleable  frame"  system.  Four  test  cases,  which  are 
documents  of  Request  for  Change  Order  Proposals,  will  be  applied.  Users  will  be 
required  to  make  a  decision  on  whether  a  certain  change  will  incur  extra  cost.  The 
objective  is  to  find  out  if  there  is  a  significant  difference  in  terms  of  time  between  the  two 
systems  for  users  to  make  a  decision. 

In  the  following  sections,  details  on  test  plans,  test  system  set-up,  test  cases,  data 
collection  and  data  analysis  will  be  discussed. 
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6.2  Pilot  Study 

A  pilot  study  was  conducted  to  gain  knowledge  and  experience  regarding  the 
design  of  the  test  system.  The  test  system  of  the  pilot  study  used  three  test  cases  that  were 
shared  by  the  standard  system  and  the  "malleable  frame"  system.  The  three  test  cases 
were  designed  to  represent  the  three  possible  cases  shown  in  Table  6. 1 .  The  pilot  study 
used  graduate  students  of  M.E.  Rinker  Sr.,  School  of  Building  Construction  (BCN).  Forty 
students  were  participated  in  the  test.  Twenty  students  used  the  standard  system  and  each 
of  them  needed  to  test  all  three  cases.  The  other  twenty  students  used  the  "malleable 
frame"  system  and  each  of  them  tested  the  same  three  cases.  The  experience  gaining 
from  the  pilot  study  suggested, 

•  A  larger  sample  size, 

•  Being  more  specific  about  asking  participants'  experience,  i.e.  using  "1-5 
years  of  experience"  rather  than  "very  familiar," 

•  Using  pair-wise  comparison, 

•  Controlling  test  steps, 

•  Controlling  timing, 

•  Re-designing  test  cases  for  pair-wise  comparison. 

Based  on  the  pilot  study,  improvements  were  made  to  the  final  test  system. 

6.3  Test  Plans 

Change  orders  are  typical  to  almost  all  kinds  of  construction  projects.  Figure  6.1, 
which  include  many  types  of  documents  such  as  a  Request  for  Information,  a  Request  for 
Change  Order  Proposal  and  a  Change  Order  Proposal,  shows  a  typical  document  flow  of 
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a  change  order  process.  In  this  research,  we  will  focus  on  one  step  in  a  contractor's 
perspective.  That  step  is  that  after  receiving  a  Request  for  Change  Order  Proposal  a 
contractor  needs  to  prepare  a  return  document,  a  Change  Order  Proposal. 

The  consequence  of  a  change  may  be  either  changes  in  cost  or  no  change  in  cost. 
Putting  it  into  the  context  of  this  research  adds  another  dimension,  which  is  whether  the 
document  is  about  defined  items  or  undefined  items.  If  the  change  order  is  about  some 
items  that  have  already  existed  in  the  user's  local  systems,  the  items  are  defined. 
Otherwise,  they  are  undefined.  Table  6. 1  shows  possible  combinations  of  these  two 
dimensions. 


Table  6.1  Possible  combinations  of  the  two  dimensions  regarding  a  change 


No  change 

Change 

Defined 

Possible 

Possible 

Un-defined 

Not  Possible 

Possible 

Among  all  combinations,  three  of  them  are  possible.  These  three  cases,  denoted 
as  "d/c",  "d/nc"  and  "ud/c",  are  "defined  with  change",  "defined  without  change"  and 
"un-defined  with  change"  respectively.  Figure  6.2  shows  a  typical  process  of  this  step. 

Since  a  "malleable  frame"  system  is  supposed  to  be  able  to  put  a  received 
document  and  related  local  information  in  the  same  window  for  users,  it  is  more  valuable 
to  identify  whether  the  received  document  is  about  some  items  that  have  been  defined  by 
the  user's  local  system  or  not.  This  idea  will  be  reflected  in  the  test  cases. 
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Request  for  Information 


Request  for  Change  Order 
Proposal 


Change  Order  Proposal 


No 


Change  Order  Directory 


Yes 


Change  Order 


Claim 


Figure  6.1  Document  flow  of  the  change  order  process 
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Step  1 :  Receiving  and  reviewing  a  request  for 
change  order  proposal 

r 

Step  2:  Evaluating  the  request  for  change  order 
proposal  with  local  information 

Step  3:  Identifying  chang 
subcontractors  involved 

e  types  and 

— d/nc 
Type  ^  


d/c  and  ud/c 

r 

Step  4:  Estimating  and  requesting  sub-quotes 

r 

Step  5:  Reviewing  estimating  and  sub-quotes 

r 

Step  6:  Preparing  a  return  document 

<  

Step  7:  Delivering  the  return  document 

Figure  6.2  A  typical  step  for  preparing  a  change  order  proposal 
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Figure  6.2  shows  a  7-step  process  for  preparing  a  change  order  proposal.  Among 
the  seven  steps,  this  research  is  only  interested  in  the  first  three  steps  while  only  step  2 
and  step  3  should  be  different  between  the  standard  system  and  the  "malleable  frame" 
system.  Thus  the  test  variable  is  designed  to  measure  the  time  for  completing  up  to  step 
3.  Figure  6.3  shows  the  differences  between  the  systems  and  the  setup  of  the  test  variable. 

In  other  words,  the  test  will  determine  if  there  is  a  statistically  significant 
difference  in  time  that  it  takes  to  decide  whether  the  change  order  request  is  a  "cost"  or 
"no  cost"  change. 


Standard 
System 

Malleable 
Frame  System 

Test  Variable 

Step  One 

Same 

Same 

Step  Two 

Different 

Different 

T 

Step  Three 

Different 

Different 

Step  Four 

Same 

Same 

Step  Five 

Same 

Same 

Step  Six 

Same 

Same 

Step  Seven 

Same 

Same 

Figure  6.3  Difference  between  the  two  test  systems  and  the  test  variable 
For  the  sake  of  simplicity,  the  tests  will  only  use  one  type  of  local  information, 
schedule  information,  because  it  does  not  matter  how  many  types  of  local  information  are 
included  in  the  tests. 
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6.4  Test  Cases 

Several  principles  are  followed  in  designing  test  cases: 

1.  The  cases  are  simple  enough  so  that  people  with  minimum  practical  experience  in 
dealing  with  change  order  cases  can  handle  the  tests.  The  purpose  of  doing  this  is  to 
reduce  any  time  differences  caused  by  different  level  of  construction  experience  and 
knowledge. 

2.  The  cases  should  be  different  enough  to  reduce  bias.  This  is  saying  that  one  case 
should  not  be  related  to  another  in  any  way.  The  differences  are  reflected  in  the 
documents  such  that  they  refer  to  different  building  items  in  different  cases.  Also  the 
differences  are  reflected  in  scheduling  such  that  the  items  belong  to  different 
categories. 

3.  Although  there  might  be  some  bias  in  term  of  the  testing  process,  i.e.  the  user  gets 
more  familiar  with  the  system  when  doing  the  fourth  test  case  than  when  doing  the 
first,  sample  tests  offer  an  effective  way  to  reduce  such  bias  to  a  minimum  level. 

4.  In  order  to  obtain  a  pair-wise  comparison,  two  pairs  of  cases  are  designed.  One  pair 
includes  Case  1  and  Case  3.  The  other  includes  Case  2  and  Case  4.  Besides,  the 
average  time  of  the  standard  system  and  that  of  the  "malleable  frame"  system  consists 
of  another  derived  pair.  Therefore  the  tests  will  have  three  pairs  shown  in  Table  6.2. 
Although  cases  in  each  pair  are  different  cases  to  avoid  bias,  they  are  designed  with 
comparable  features  such  as  the  size  of  documents,  the  size  of  images,  lines  of  text, 
the  size  of  related  schedule  information  so  that  it  is  reasonable  to  assume  that  they  are 
comparable. 
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Pair  1,  Case  1  and  Case  3,  represents  a  situation  that  items  or  activities  that  a  Request 
for  Change  Order  Proposal  discusses  have  been  defined  in  the  document  viewer's 
local  system.  Pair  2,  Case  2  and  Case  4,  represents  a  situation  that  items  or  activities 
that  a  Request  for  Change  Order  Proposal  discusses  have  not  been  defined  in  the 
document  viewer's  local  system.  Pair  3,  average  cases  of  the  standard  system  and  the 
"malleable  frame"  system,  represents  a  cross  media  and  general  condition.  Since 
these  pairs  represent  different  situations,  the  hypothesis  test  will  be  repeated  for  each 
of  the  situations. 


Table  6.2  Pair-wise  Cases 


Malleable  Frame  Sysl 

tem 

Case  3 

Case  4 

Average 

Standard  System 

Case  1 

Pair  1 

Case  2 

Pair  2 

Average 

Pair  3 

6.5  Test  System  Design 

In  addition  to  test  case  design,  major  considerations  regarding  the  test  system 
design  include  sample  testing,  flow  control,  timing  and  survey.  Details  of  the  test  system 
are  discussed  in  Appendix  C. 
6.5.1  Sample  Testing 

One  of  the  important  steps  to  reduce  bias  introduced  by  learning  curve  is 
conducting  sample  testing  before  taking  actual  tests.  Two  sample  tests  are  used  by  the 
test  systems,  one  for  the  standard  system  and  the  other  for  the  "malleable  frame"  system. 
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Sample  tests  are  designed  in  such  a  way  that  the  process  for  conducting  sample 
testing  is  exactly  the  same  as  taking  normal  tests.  In  this  way,  after  a  couple  of  times  of 
practice,  even  just  once,  a  user  can  be  reasonably  confident  to  take  normal  tests. 

6.5.2  Flow  Control 

Since  the  test  system  is  on-line,  it  is  designed  for  self-help  tests,  which  means 
there  will  not  be  anybody  out  there  helping  users  to  complete  tests.  Thus  assuring  that  all 
users  follow  the  same  process  is  extremely  important.  So  the  test  system  uses  a  lot  of  user 
interface  features  to  control  the  flow  of  testing  to  make  sure  that  every  user  follows  the 
same  process.  Appendix  C  has  detailed  explanations  on  this  topic. 

6.5.3  Timing 

Time  is  crucial  for  this  research.  What  is  important  to  this  research  is  the  period 
of  time  from  the  point  that  all  relevant  information  is  loaded  to  the  point  that  a  user's 
decision  is  made.  This  time  period  is  controlled  by  user  interactions  so  that  unrelated 
time  will  not  be  included.  Please  refer  to  Appendix  C  for  details 

6.5.4  Survey 

Besides  time,  other  information  such  as  the  user's  knowledge  about  change  orders 
and  the  user's  satisfaction  with  using  the  "malleable  frame"  system  is  collected.  Survey 
questions  were  asked  after  each  "malleable  frame"  test  was  completed.  Appendix  C  has  a 
sample  of  the  survey. 
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6.6  Data  Collection 

6.6.1  Sampling 

This  research  used  samples  of  students  of  M.E.  Rinker,  Sr.,  School  of  Building 
Construction  (BCN).  Reasons  for  such  a  substitution  are  that  firstly  most  of  BCN 
students,  especially  seniors  and  graduate  students,  have  relevant  construction  education 
and  some  even  already  have  relevant  construction  experience.  Therefore  they  understand 
how  to  deal  with  a  Request  for  Change  Order  Proposal  very  well.  Secondly,  the  objective 
of  the  test  is  not  to  test  how  the  systems  can  handle  complicated  information  of  a  real 
construction  project  by  professionals.  Rather  it  is  to  compare  a  simple  feature  between 
two  kinds  of  systems  since  malleability  is  reflected  as  simply  interface  features  in  the  test 
systems.  Thirdly,  the  test  cases  are  deliberately  designed  to  be  simple  enough  so  that 
more  work  experience  and  extra  knowledge  will  not  become  an  advantage  and  will 
certainly  not  affect  the  time  needed  for  making  a  simple  decision.  Based  on  these 
assumptions,  BCN  graduating  seniors  and  graduate  students  will  be  used  as  samples  for 
this  test. 

6.6.2  Sample  Size 

Ideally  a  sample  size  should  be  decided  by  the  following  formula  (Byrkit,  1987) 

n  =  (Z„;,*a/E)^ 

Where,  a  is  the  level  of  significance  (1-a  is  called  confidence  level);  a  is  the 
standard  deviation  and  E  is  called  "maximum  error".  In  this  research  a  and  E  are 
unknown,  so  other  approaches  are  required.  Some  research  suggests  that  a  sample  size  of 
30  or  over  is  good  enough  and  acceptable  (Marks,  1997).  Because  if  a  sample  size  is 
larger  than  30,  the  Central  Limit  Theory  can  be  invoked  and  the  distribution  of  the 
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sample  average  can  be  regarded  as  normal.  In  this  research,  a  sample  size  of  46  is 
applied. 

6.6.3  Collected  Data 

Several  types  of  data,  shown  in  Table  6.3,  are  collected  via  the  "Survey  Answer 
Sheet"  (see  Appendix  C). 

In  total,  there  are  49  samples  collected.  However,  three  of  them  are  incomplete 
(They  only  have  data  for  sample  tests).  Among  the  rest  46  samples,  one  does  not  indicate 
years  the  level  of  experience,  so  there  are  45  samples  used  for  user  satisfaction  analysis. 
Overall,  46  samples  are  used  for  hypothesis  testing  (See  Table  6.4). 


Table  6.3  Data  Collected 


Data  and  information 

Reasons  to  collect 

Knowledge  of  Change  Orders 

To  collect  background  information 

Time 

To  compare  the  two  systems 

User  satisfaction 

To  check  user  satisfaction  to  the  "malleable  frame" 
system 

Further  control  over  display 

To  understand  user's  needs  for  malleability 

Following  are  the  data  compiled  according  to  each  of  the  types.  Analysis  will  be 
given  later  in  this  chapter. 
Knowledge  of  Change  Orders 

The  survey  asked  respondents  about  their  knowledge  of  construction  change 
orders  on  a  scale  of  "Excellent  (more  than  10  years  of  working  knowledge  of  change 
orders)  ",  "Very  familiar  (5-10  years  of  working  knowledge  of  change  orders)  ", 
"Familiar  (0-5  years  of  working  knowledge  of  change  orders)  ",  "Not  Familiar  (school 
experience)"  and  "Don't  know  at  all". 
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This  information  is  used  as  background  information  only  and  nothing  more  since 
this  research  is  not  focused  on  comparing  time  between  different  knowledge  groups. 
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Figure  6.4  Respondents  by  knowledge  of  change  orders 
Figure  6.4  shows  the  number  of  respondents  by  the  knowledge  of  change  orders. 
It  shows  that  all  of  the  respondents  have  at  least  school  knowledge  of  change  orders. 
Time  for  Completing  Tests 

Time  for  completing  test  cases  is  collected  and  compiled  in  pair-wise  format, 
shown  in  Table  6.4.  These  data  are  used  for  computing  sample  statistics.  In  the  table, 
"SS"  stands  for  "Standard  System"  and  "MFS"  stands  for  "Malleable  Frame  System." 
User  Satisfaction 

Beside  quantitative  analysis  based  on  time,  two  questions  are  asked  to  find  out  user's 
satisfaction  towards  the  "malleable  frame"  system  in  order  to  have  a  qualitative 
understanding  as  well.  The  first  question  is  "Do  you  find  it  helpfiil  by  putting  the  request 
for  change  order  proposal  and  related  project  information  on  the  same  page  when  dealing 
with  change  orders?"  Answers  were  collected  on  a  scale  of  "Extremely  helpful",  "Very 
helpful",  "Helpful",  "Not  very  helpfial"  and  "Not  helpful  at  all". 
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Table  6.4  Time  for  Completing  Tests  (Unit:  second) 
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Figure  6.5  Answers  to  questions  about  user  satisfaction 


Figure  6.6  Answers  to  the  questions  regarding  controls  over  display 
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The  second  question  is  "As  an  end  user,  do  you  wish  to  have  control  over  how 
the  request  for  change  order  proposal  and  the  related  project  information  are  presented  to 
you  if  they  are  on  the  same  page?"  Answers  were  collected  on  a  scale  of  "Yes",  "Not 
sure"  and  "Not." 

The  results  for  these  two  questions  are  shown  in  Figures  6.5  and  6.6  respectively. 
6.6.4  User  Satisfaction  within  the  Same  Experience  Level 

This  section  discusses  some  observations  about  user  satisfaction  within  the  same 
experience  level. 

With  five  or  more  years  of  experience 

Table  6.5  shows  the  results  collected  from  people  with  five  or  more  years  of 
experience. 


Table  6.5  Data  for  the  Group  with  Five  or  More  Years  of  Experience 


No. 

Case  1 

Case  3 

Case  2 

Case  4 

Case  3 

Case  4 

Case  3 

Case  4 

(Second) 

(Second) 

(Second) 

(Second) 

Ql 

Ql 

Q2 

Q2 

1 

27 

37 

14 

41 

EH 

EH 

Yes 

Yes 

2 

60 

27 

21 

39 

EH 

EH 

Yes 

Yes 

3 

52 

36 

26 

45 

EH 

EH 

Yes 

Yes 

Average 

50 

33 

20 

42 

Note:  "EH"  stands  for  "Extremely  Helpful";  "Ql"  stands  for  the  first  question  of  the 
survey;  "Ql"  stands  for  the  second  question  of  the  survey. 

According  to  Table  6.5,  all  of  the  respondents  in  this  group  (with  five  to  ten  years 

of  experience)  indicate  that  the  "malleable  frame"  system  is  "Extremely  helpful"  and 

users  would  like  to  have  more  controls  over  display.  However,  since  there  are  only  three 

samples  in  this  group,  it  is  impossible  to  make  any  statistical  decision. 
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With  One  to  Five  Years  of  Experience 


Table  6.6  shows  the  results  collected  from  people  with  one  to  five  years  of 
experience. 


Table  6.6  Data  for  the  Group  with  One  to  Five  Years  of  Experience 


No. 

Case  1 
(Second) 

Case  3 
(Second) 

Case  2 
(Second) 

Case  4 
(Second) 

Case  3 
Qi 

Case  4 
QI 

Case  3 
Q2 

Case  4 
02 

1 

84 

66 

58 

77 

EH 

EH 

Yes 

Yes 

2 

55 

26 

57 

56 

VH 

EH 

Yes 

Yes 

3 

22 

38 

31 

21 

VH 

VH 

NS 

NS 

4 

55 

34 

36 

49 

EH 

EH 

NS 

NS 

5 

32 

15 

51 

27 

VH 

VH 

Yes 

Yes 

6 

32 

15 

51 

27 

VH 

VH 

Yes 

Yes 

7 

12 

33 

13 

28 

H 

H 

No 

No 

8 

40 

36 

32 

26 

NVH 

NVH 

Yes 

Yes 

9 

62 

25 

38 

27 

H 

H 

Yes 

Yes 

10 

70 

33 

17 

27 

VH 

VH 

Yes 

Yes 

11 

77 

82 

77 

74 

EH 

EH 

Yes 

Yes 

12 

70 

24 

60 

25 

EH 

EH 

NS 

NS 

13 

55 

34 

36 

49 

EH 

EH 

NS 

NS 

14 

38 

80 

26 

37 

EH 

EH 

Yes 

Yes 

15 

138 

41 

39 

59 

VH 

VH 

No 

Yes 

16 

138 

22 

42 

54 

VH 

VH 

Yes 

Yes 

Average 

61 

38 

41 

41 

for  "Helpful";  "NVH"  stands  for  "Not  VeryHelpftil";  "QI"  stands  for  the  first  question 
of  the  survey;  "NS"  stands  for  "Not  Sure";  QI  stands  for  the  second  question  of  the 
survey. 

Figure  6.7  shows  the  number  and  the  percentage  of  responses  relafing  to  user 
satisfaction  at  different  levels,  which  are  "Extremely  helpful",  "Very  helpfiil",  "Helpful", 
"Not  very  helpfiil",  and  "  Not  helpful  at  all." 

Figure  6.8  shows  the  number  and  the  percentage  of  responses  regarding  user 
control  over  the  document  display  format. 
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Figure  6.7  Answers  to  the  question  about  user  satisfaction  by  people  with  one  to  five 
years  of  experience 
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Figure  6.8  Answers  to  the  question  regarding  user  control  over  the  document  display 
format  by  people  with  one  to  five  years  of  experience 
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With  School  Experience 

Table  6.7  shows  samples  collected  from  people  with  school  experience. 


Table  6.7  Data  for  the  Group  with  School  Experience 


No. 

Case  1 
(Second) 

Case  3 
(Second) 

Case  2 
(Second) 

Case  4 
(Second) 

Case  3 
01 

Case  4 
Ql 

Cases 
Q2 

Case  4 
Q2 

1 

23 

52 

39 

31 

VH 

VH 

Yes 

Yes 

2 

17 

47 

24 

20 

EH 

NHAL 

No 

No 

3 

36 

37 

30 

42 

EH 

VH 

Yes 

Yes 

4 

25 

51 

46 

54 

VH 

VH 

Yes 

Yes 

5 

33 

25 

66 

28 

EH 

VH 

Yes 

Yes 

6 

41 

25 

68 

34 

EH 

EH 

Yes 

Yes 

7 

60 

27 

21 

39 

EH 

EH 

Yes 

Yes 

8 

28 

51 

20 

32 

H 

VH 

Yes 

Yes 

9 

76 

32 

75 

49 

VH 

H 

Yes 

Yes 

10 

53 

41 

48 

57 

EH 

VH 

No 

No 

11 

66 

34 

70 

21 

VH 

VH 

Yes 

Yes 

12 

42 

32 

33 

14 

H 

VH 

NS 

NS 

13 

37 

17 

36 

21 

EH 

EH 

Yes 

Yes 

14 

66 

34 

70 

21 

VH 

VH 

Yes 

Yes 

15 

63 

29 

47 

44 

EH 

VH 

Yes 

Yes 

16 

45 

38 

24 

33 

VH 

VH 

No 

No 

17 

23 

26 

10 

8 

H 

H 

NS 

NS 

18 

42 

38 

17 

8 

NVH 

NVH 

No 

No 

19 

44 

47 

40 

21 

H 

H 

NS 

NS 

20 

36 

40 

80 

32 

EH 

EH 

Yes 

NS 

21 

89 

38 

62 

36 

VH 

VH 

Yes 

Yes 

22 

137 

37 

17 

14 

H 

H 

NS 

NS 

23 

67 

57 

22 

111 

VH 

VH 

NS 

NS 

24 

86 

22 

102 

39 

VH 

VH 

NS 

Yes 

25 

86 

39 

33 

30 

H 

H 

NS 

NS 

26 

111 

37 

92 

39 

EH 

EH 

NS 

NS 

Average 

55 

37     1  46 

34 

Note:  "EH"  stands  for  "Extremely  Helpful";  "VH"  stands  for  "Very  Helpful";  "H"  stands 
for  "Helpful";  "NVH"  stands  for  "Not  Very  Helpful";  "NHAL"  stands  for  "Not  Helpful 
At  All";  "Ql"  stands  for  the  first  question  of  the  survey;  "NS"  stands  for  "Not  Sure";  Ql 
stands  for  the  second  question  of  the  survey. 
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Figure  6.9  and  6.10  indicate  that  most  of  the  people  with  school  experience 
reported  that  the  "malleable  frame"  system  was  helpful  to  both  cases  and  many  of  them 
would  like  to  have  more  user  control  over  the  document  display  format. 

The  observations  obtained  from  Table  6.5  and  Figure  6.7  to  6.10  indicate  that  all 
three  groups,  namely  5  to  10  years  of  experience,  1  to  5  years  of  experience  and  school 
experience,  have  similar  patterns.  All  three  groups  appear  to  indicate  that  the  majority 
reported  that  the  "malleable  frame"  system  was  "Helpful."  (See  Table  6.5  and  Figure  6.7 
and  6.9)  Meanwhile,  many  with  less  than  five  years  of  experience  indicated  that  they 
were  not  sure  it  they  needed  more  control  over  the  document  display  format  (See  Figure 
6.8  and  6.10). 

6.6.5  User  Satisfaction  Comparison  between  Different  Experience  Groups 

The  previous  section  discusses  observations  about  user  satisfaction  within  the 
same  experience  level.  In  this  section,  focus  is  on  the  comparison  of  user  satisfaction 
between  groups  of  different  experience  levels. 
Case  3 

Figure  6.1 1  and  6.12  show  the  comparison  of  user  satisfaction  with  using  the 
"malleable  frame"  system.  Figure  6.12  shows  accumulative  values.  Both  diagrams 
indicate  that  the  more  experienced  users  are  the  more  satisfied  they  are. 

Figure  6.13  and  6.14  shows  the  comparison  of  the  desire  for  more  controls  over 
display.  Both  diagrams  seem  to  indicate  the  same  results,  which  there  is  a  larger 
percentage  of  experienced  users  who  would  like  to  have  user  controls  over  the  document 
display  format. 
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Figure  6.9  Answers  to  the  question  about  user  satisfaction  by  people  with  school 
experience 
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Figure  6.10  Answers  to  the  question  regarding  controls  over  display  by  people  with 
school  experience 
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Figure  6. 1 1  Answers  to  the  question  about  user  satisfaction  for  Case  3  by  experience 
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Figure  6.12  Accumulative  percentage  of  user  satisfaction  for  Case  3  by  experience 
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Figure  6.13  Answers  to  the  question  regarding  controls  over  display  for  Case  3  by 
experience 
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Figure  6.14  Accumulative  percentage  of  user's  desire  for  more  user  control  over  the 
document  display  format  for  Case  3  by  experience 
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Figure  6.15  Answers  to  the  question  about  user  satisfaction  for  Case  4  by  experience 
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Figure  6.16  Answers  to  the  question  about  user  satisfaction  for  Case  4  by  experience 


128 


120% 
100% 
80% 
60% 
40% 
20% 
0% 


Yes 


Not  sure 


■  School  Experience 


54% 


31% 


15% 


1-5  Years  of  Experience 


63% 


25% 


12% 


■  5  More  Years  of  Experience 


100% 


0 


0 


Figure  6. 17  Answers  to  the  question  regarding  controls  over  display  for  Case  4  by 
experience 
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Case  4 

Similar  approaches  are  used  to  analyze  data  for  Case  4.  Figure  6.15  and  6.16 
indicate  a  similar  result  as  that  for  Case  3,  which  is  users  with  more  work  experienced 
indicated  more  satisfaction  with  the  "malleable  frame"  system.  Also  experienced  users 
seem  to  like  the  idea  to  have  more  controls  over  display  (See  Figure  6.17  and  6.18). 

6.7  Hypothesis  Test 

The  methodology  for  testing  hypothesis  follows  a  formal  procedure  of  statistical 
analysis.  The  formal  procedure  for  testing  hypotheses  about  two  population  means 
normally  has  five  steps  (Minium,  &  Clarke,  1982,  Triola,  1989).  They  are 

1 .  Formulating  the  statistical  hypothesis  and  selecting  a  level  of  significance. 

2.  Determining  a  desired  sample  size  and  selecting  samples. 

3.  Calculating  sample  statistics. 

4.  Identifying  the  region  of  rejection. 

5.  Making  statistical  decisions  and  conclusions. 

Following  sections  will  discuss  each  of  the  five  steps  in  order  to  draw  a 
conclusion  for  this  test. 
6.7.1  Hypothesis 

This  research  is  interested  in  determining  whether  the  "malleable  frame"  system 
is  better  than  the  standard  system  in  terms  of  time.  Thus  the  hypothesis  is  presented  as 
following: 

Uq-.  ^„  -     =  0  (Null  hypothesis) 

H^:  )a„  -     <  0  (Alternative  hypothesis) 
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Ho  states  "there  is  no  difference  between  the  'malleable  frame'  system  and  the 
standard  system  in  terms  of  time  for  making  a  decision."     states  "the  'malleable  frame' 
system  is  quicker  than  the  standard  system  in  terms  of  time  for  making  a  decision." 
and  \JL,  are  population  means  of  the  "malleable  frame"  system  and  the  standard  system 
respectively. 

A  statistical  decision  will  be  made  based  on  the  following  rule:  (Byrkit,  1987, 
Mansfield,  1986) 

"When  the  alternative  hypothesis  is  ji,  - 1^2  ^  0,  reject  the  null  hypothesis  if  t 
exceeds  t^2  or  less  than  - 1^2-  When  the  alternative  hypothesis  is  li,  - 1^2  <  0>  reject  the  null 
hypothesis  if  t  <      When  the  alternative  hypothesis  is  |a,  -  |i2  >  0,  reject  the  null 
hypothesis  if  t>t,  (Mansfield,  1986,  p349)." 

Where  r„  can  be  obtained  from  Student's  /  distribution  included  in  many  statistics 
books;  and  /  is  obtained  from  calculations  by  the  SPSS  tool. 

The  level  of  significance,  which  specifies  how  rare  a  sample  result  must  be  in 
order  to  reject  a  hypothesis,  is  commonly  set  at  either  0.01  or  0.05.  Usually  most  research 
selects  0.05  (Minium,  &  Clarke,  1982,  Byrkit,  1987,  Triola,  1989).  This  research  will 
accept  5%  level  of  significance  (or  95%  confidence  level). 
6.7.2  Desired  Sample  Size  and  Selected  Sample  Size 

As  stated  earlier,  a  desired  sample  size  can  be  decided  either  by  using  the  formula 
or  using  a  size  of  30  or  more  (Marks,  1997).  This  research  uses  a  sample  size  of  46. 
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6.7.3  The  Standard  System  vs  the  "Malleable  Frame"  System  Statistical  Analysis 

Data  are  analyzed  by  SPSS  with  a  level  of  significance  of  5%  (or  95%  confidence 
level).  Results  are  shown  in  Table  6.8  in  which  "SS"  stands  for  "Standard  System"  and 
"MFS"  stands  for  "Malleable  Frame  System.  " 


Table  6.8  The  Result  of  Statistical  Analysis 


Pair  One 

Pair  Two 

Pair  Three 

Case  1 
(SS) 

Case  3 
(MFS) 

Case  2 
(SS) 

Case  4 
(MFS) 

Average 
(SS) 

Average 
(MFS) 

Mean 

58.54 

36.59 

42.52 

37.96 

51.11 

37.15 

Standard 
Deviation 

33.06 

14.25 

22.23 

19.99 

21.87 

14.08 

Standard 
Error  of 
Mean 

4.88 

2.10 

3.28 

2.95 

3.22 

2.08 

Pearson's  R 

-0.046 

0.15 

0.24 

Degree  of 
Freedom 

45 

45 

45 

t  Value 

-4.07 

-1.12 

-4.11 

Pearson's  R  is  a  measure  of  linear  association  between  two  variables.  The  value 
of  R  ranges  between  -1  (a  perfect  negative  relationship  in  which  all  points  fall  on  a  line 
with  negative  slope)  and  +1  (a  perfect  positive  relationship  in  which  all  points  fall  on  a 
line  with  positive  slope).  A  value  of  0  indicates  no  linear  relationship. 
6.7.4  Normalized  Comparison  Test 

In  order  to  reduce  variance,  a  further  normalized  test  was  conducted  by  using  pair 
3  (average  cases)  and  eliminating  data  sets  that  have  large  deviation.  The  criterion  used 
for  eliminating  data  is  to  reduce  the  data  range  by  20%.  For  example,  the  data  range  for 
the  standard  system  is  from  13  to  102  (see  Table  6.4);  while  it  is  17  to  84  (see  Table  6.4) 
for  the  "malleable  frame"  system.  Normalizing  means  that  data  falling  in  the  range  of 
0%-10%  and  90%- 100%  are  removed.  Consequently,  the  data  range  for  the  standard 


system  is  reduced  to  22  to  93  and  the  data  range  for  the  "malleable  frame"  system  is 
reduced  to  24  to  77.  The  normalized  t-test  will  only  use  data  within  the  new  data  ranges 
for  each  case.  Table  6.9  shows  the  data  sets  conforming  to  the  new  data  ranges. 


Table  6.9  Normalized  Data  Sets  for  the  Average  Cases 


Average  SS 

Average  MFS 

71 

72 

56 

41 

27 

30 

46 

42 

36 

31 

50 

26 

44 

30 

65 

25 

46 

42 

32 

59 

84 

50 

90 

38 

91 

53 

31 

42 

33 

40 

53 

36 

50 

27 

55 

30 

41 

33 

24 

42 

76 

41 

51 

49 

68 

28 

68 

28 

55 

37 

35 

36 

42 

34 

58 

36 

76 

37 

77 

26 

60 

35 

41 

33 

39 

41 

133 

By  using  SPSS,  following  statistics  are  obtained  (See  Table  6.10). 


Table  6.10  Statistics  for  the  normalized  test 


Sample  Statistics 

Malleable  Frame  System 

Standard  System 

Mean 

37.88 

53.67 

Standard  Deviation 

10.13 

18.25 

Standard  Error  of  Mean 

3.18 

1.77 

Degree  of  Freedom 

32 

32 

Person's  R 

0.115 

t  -  Value 

-4.57 

6.7.5  Sample  Size  Analysis 

The  population  distribution  is  assumed  to  be  normal  and  the  following  equation 
can  be  used  to  estimate  a  desired  sample  size. 

n  =  (Z„/,*a/E)^ 

Where,  a  is  the  level  of  significance;  a  is  the  standard  deviation  and  E  is  called 
"maximum  error". 

Also  it  is  assumed  that  the  acceptable  maximum  error,  E,  may  be  5  seconds,  8 
seconds,  and  10  seconds.  The  level  of  significance  is  0.1  and  0.05. 

Table  6.8  shows  that  33.06  is  the  maximum  standard  deviation,  which  will  be 
used  to  estimate  sample  size.  Table  6. 1 1  shows  the  results  of  calculation  according  to  the 
equation  shown  above. 


Table  6.11  Sample  Size  Analysis  by  Level  of  Significance  and  Maximum  Error 


Maximum  Error  (El 

Level  of  Significance 

5  (seconds) 

8  (seconds) 

10  (seconds) 

0.10 

118 

46 

29 

0.05 

168 

66 

42 
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The  results  shown  in  Table  6. 1 1  indicate  that  when  using  the  0.05  level  of 
significance  (or  95%  confidence  level),  the  desired  sample  size  should  be  168,  66,  and  42 
corresponding  to  5  seconds,  8  seconds  and  10  seconds  of  maximum  error.  The  sample 
size  of  46  used  in  this  research  can  expect  the  maximum  error  of  10  seconds. 

On  the  other  hand,  with  the  sample  size  of  46,  it  is  95%  confident  that  the  sample 
size  is  acceptable  with  a  maximum  error  of  10  seconds;  or  it  is  90%  confident  that  the 
sample  size  is  acceptable  with  maximum  error  of  8  seconds.  The  sample  of  the 
normalized  test  is  acceptable  with  90%  confidence  with  a  maximum  error  of  10  seconds. 

6.7.6  The  Region  of  Rejection 

With  a  =  0.05  (level  of  significance)  and  df  =  45  (degree  of  freedom),    will  be 
1.679  according  to  Student's  t  distribution  (Minium,  &  Clarke,  1982). 

For  the  "normalized"  test,  with  a  =  0. 10  (level  of  significance)  and  df  =  32 
(degree  of  freedom),    will  be  1.308  according  to  Student's  t  distribution. 

6.7.7  Statistical  Decisions 

Based  on  above  analysis,  the  following  statistical  observations  can  be  made. 
1.  Pair  One:  Case  1  and  Case  3 

Since  t  =  -4.07  and  -/„  =  -1.679,  /  <     becomes  with  a  level  of  significance  of 
0.05  (or  95%  confidence  level).  Therefore,  the  null  hypothesis  is  rejected, 
indicating  that  a  significant  difference  exists  between  the  standard  system  and 
the  "malleable  frame"  system  in  terms  of  the  time.  In  other  words,  according 
to  these  two  cases,  the  time  needed  by  persons  using  the  "malleable  frame" 
system  is  significantly  less  than  the  time  needed  by  persons  using  the  standard 
system. 
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2.  Pair  Two:  Case  2  and  Case  4 

Since  f  =  -1.12  and  -t^  =  -1.679,  /  <  -^„is  not  true  at  the  significance  level  of 
0.05  (or  95%  confidence  level).  Therefore,  the  null  hypothesis  is  accepted, 
which  means  that  there  is  no  significant  difference  in  terms  of  time  between 
using  the  standard  system  and  by  the  "malleable  frame"  system.  So  in  this 
case,  using  the  "malleable  frame"  system  is  not  faster  than  using  the  standard 
system  to  make  a  decision. 

3.  Pair  Three:  Two  average  cases 

Since  t  =  -4A  \  and  -/„  =  -1.679,  /  <  -t^  is  true  at  the  significance  level  of  0.05 
(or  95%  confidence  level).  Therefore  the  null  hypothesis  is  rejected, 
indicating  a  significant  difference  exists  between  the  standard  system  and  the 
"malleable  frame"  system  in  terms  of  the  time. 

For  the  "normalized"  test,  since  /  =  -4.57  and  -/„  =  -1 .308,  t  <  -t^  is  true. 
Therefore,  the  null  hypothesis  is  rejected,  indicating  a  significant  difference 
exists  between  the  standard  system  and  the  "malleable  frame"  system  as  well. 

6.8  Summary 

This  chapter  focuses  on  the  testing  of  hypothesis  by  setting  up  two  types  of  test 
systems.  One  system  simulates  a  system  without  malleability  and  the  other  simulates  a 
system  with  malleability. 

Sample  data  are  collected  from  BCN  graduate  students  and  seniors  most  of  whom 
have  a  good  knowledge  about  change  orders.  Collected  data  are  analyzed  using  standard 
statistical  tools  and  the  research  hypothesis  is  tested. 
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Statistical  analysis  showed  that  in  two  of  the  three  cases  tested  the  "malleable 
frame"  system  was  significantly  faster  in  terms  of  the  time  it  took  the  user  to  decide 
whether  or  not  the  change  involved  cost  or  not.  However,  in  the  case  that  document 
viewer's  local  information  system  does  not  have  information  about  the  item  that  the 
document  has  discussed,  the  results  indicated  that  the  "malleable  frame"  system  will  not 
always  improve  the  efficiency  of  document  processing.  Overall,  the  results  suggested  that 
if  the  document  processing  requires  local  information  and  the  information  is  available, 
using  a  "malleable  frame"  system  is  at  least  not  slower  that  using  a  standard  system. 

As  to  user  satisfaction,  results  indicated  that  most  respondents  were  very  satisfied 
with  the  "malleable  frame"  system  and  reported  that  the  "malleable  frame"  system  was 
helpful  (96%  in  Case  3  and  94%  in  Case  4).  However,  many  of  them  are  not  clear  as  to 
whether  they  need  more  control  over  the  information  display.  Such  results  were  observed 
in  each  of  the  knowledge  groups,  i.e.  5  or  more  years  of  experience,  1  to  5  years  of 
experience  and  school  experience.  In  addition,  comparisons  between  different  knowledge 
indicated  that  users  with  more  work  experience  seemed  to  be  more  satisfied  with  the 
"malleable  frame"  system  and  more  interested  in  having  control  over  the  information 
display. 


CHAPTER  7 
CONCLUSION 

The  objectives  of  this  research  have  been  stated  as:  (1)  to  test  the  feasibility  of  a 
"malleable  frame"  system  based  on  currently  available  technology;  (2)  to  test  if  a  system 
with  malleability  is  better  in  terms  of  time  to  complete  document  processing  than  a 
system  without  malleability.  Thus  conclusions  will  be  drawn  from  the  both. 

7.1  Technical  Feasibility 

In  order  to  evaluate  the  feasibility  of  implementing  such  a  system,  this  research 
investigated  related  design  methodologies,  implementation  tools,  and  results  of  the 
implementation. 
7.1.1  Design  Methodologies 

There  are  two  types  of  design  methodologies  involved  in  this  research,  one  for  the 
design  of  a  "malleable  frame"  and  the  other  for  a  "malleable  frame"  system. 
Methodology  for  the  Design  of  A  "Malleable  Frame" 

A  "malleable  frame"  is  a  neutral  document  format.  In  the  Web  computing 
environment,  a  meta-language,  called  extended  Markup  Language  (XML),  is  being 
developed  by  the  World  Wide  Web  Consortium  (W3C).  XML,  a  sub-set  of  SGML 
(Standard  Generalized  Markup  Language),  can  be  used  for  develop  system  independent 
neutral  data  format.  Methodologies  for  developing  SGML  applications  are  well 
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documented  (Van  Herwijnen,  1994,  Travis,  &  Waldt,  1995,  Maler,  &  Andaloussi,  1996, 
Donovan,  1997). 

In  this  research  a  top  down  approach  is  used  to  develop  a  sample  request  for 
change  order  proposal  DTD.  Such  an  approach  is  very  straightforward  and  the  results  are 
good  enough  to  serve  as  a  neutral  data  format.  However,  one  of  the  possible  limitations  is 
that  information  included  in  the  DTD  is  limited  to  what  appears  on  the  document 
themselves.  Thus  if  a  set  of  documents  that  is  used  for  document  analysis  is  not  complete 
enough,  the  derived  DTD  will  most  likely  contain  flaws. 

There  are  other  approaches  that  can  be  used  such  as  a  bottom  up  approach  and  a 
combined  approach.  A  bottom  up  approach  looks  at  the  entire  business  process  that  a 
certain  type  of  document  is  involved  in  rather  than  only  a  particular  set  of  documents. 
Object  oriented  analysis  will  be  applied  to  find  out  all  of  the  objects  that  are  involved  in 
the  entire  process.  In  this  way,  the  bottom  up  approach  provides  a  more  comprehensive 
scope  from  which  a  particular  type  document  DTD  can  be  derived. 

A  combined  approach  lies  some  where  between  the  top  down  approach  and  the 
bottom  up  approach.  As  of  this  writing,  the  author  of  this  dissertation  is  using  this 
approach  in  developing  construction  document  schemas  (Similar  to  DTD)  for  a 
construction  software  company. 

Methodology  for  the  Design  of  A  "Malleable  Frame"  System 

The  "malleable  frame"  system  is  a  dynamic  hypermedia  system  (Zhu,  1999).  This 
area  has  been  well  studied  and  documented.  Besides  some  previous  methodologies  such 
as  the  g-IBIS  (Conklin,  &  Begeman,  1988)  and  the  Dexter  Hypertext  Reference  Model 
(Halasz,  &  Schwartz,  1990,  Halasz,  &  Schwartz,  1994),  three  most  influential  design 
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methodologies  are  used  today  (Garzotto,  Paolini,  &  Schwabe,  1995,  Schwabe,  Rossi,  & 
Barbosa,  1996,  Isakowitz,  Stohr,  &  Balasubramanian,  1995).  They  are  Hypermedia 
Development  Method  (HDM),  Object  Oriented  Hypertext  Development  Methodology), 
and  RMM  (Relationship  Management  Methodology).  Although  they  are  different  in 
details,  the  three  methodologies  bear  very  strong  similarities,  which  can  be  summarized 
as: 

•  Separate  hypermedia  design  and  implementation 

•  Modularized  hypermedia  applications  with  conceptual  schema,  navigational  schema 
and  presentation  schema 

Following  the  three-schema  approach,  the  Kaleidoscope  software  was  previously 
developed  (Zhu,  1999). 
7.1.2  Implementation  Tools 

Contemporary  computer  technology  has  provided  a  rich  set  of  implementation 
tools  for  solving  our  problems.  As  far  as  this  research  is  concerned,  three  types  of  tools 
are  critical  i.e.  an  XML  parser,  XML  and  database  integration  tools  and  Web  oriented 
programming  language. 
XML  Parsers 

There  are  many  XML  parsers  available  for  free.  Many  of  them  only  do  document 
validations.  However,  there  are  two  XML  parsers  that  are  capable  of  both  validating  a 
XML  document  and  generating  a  parse  tree  of  the  XML  document.  These  two  parsers 
have  developed  by  Microsoft  (Paoli,  Schach,  Lovett,  Layman,  &  Cseri,  1997)  and  IBM 
(http://www.IBM.com)  respectively. 
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This  research  applies  the  IBM  parser  because  it  strictly  complies  with  the  W3C 
Document  Object  Model  (DOM). 

Microsoft  IE4  uses  a  different  Document  Object  Model  than  that  of  the  W3C's. 
However,  IE5  has  started  to  support  the  W3C's  DOM  with  some  extensions. 
XML  and  Database  Integration  Tools 

Many  database  vendors  have  moved  quickly  to  incorporate  XML  technology  into 
their  database  technology.  ColdFusion  is  the  first  to  propose  the  integration  of  XML  and 
database  technology  by  using  WDDX  (Web  Distributed  Data  eXchange).  Oracle, 
Informix,  Object  Design  and  POET  are  also  moving  to  that  direction.  Although  it  takes  a 
while  for  the  computer  industry  to  complete  absorb  XML  technology  and  provide  full- 
brown  applications  for  end  users,  such  integration  is  the  trend  and  will  prevail  soon 
(Mendel,  1999). 
Programming  Tools 

Besides  tools  discussed  above,  the  implementation  of  Kaleidoscope  is  completed 
by  using  Java  programming.  Java  programming  language  is  designed  for  IntemetAVeb 
applications.  It  provides  a  rich  set  of  classes  dealing  with  the  intenet/Web  programming, 
user  interface  programming,  concurrent  programming  and  many  other  applications. 
These  features  make  Java  programming  language  an  ideal  tool  for  the  implementation  of 
Kaleidoscope. 

That  this  research  uses  Java  for  implementation  does  not  mean  other  technologies 
are  not  available  or  not  appropriate.  On  the  contrary,  other  Web  tools  such  DHTML  and 
ASP  can  be  used  perfectly  to  implement  such  a  system. 
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Results  of  the  Tmplementation 

The  system,  Kaleidoscope,  reveals  that: 

•    Document  Interpretation.  A  construction  document  prepared  in  a  neutral 
format,  an  XML  format,  can  be  precisely  interpreted  by  Kaleidoscope.  The 
design  of  document  structure  will  eventually  affect  the  malleability  of  a 
document.  For  example,  if  a  "sender"  and  his  "address"  are  combined  as  one 
element,  the  Kaleidoscope  will  have  no  way  to  retrieve  other  information,  for 
example  a  Web  page,  of  the  sender.  This  indicates  that  the  DTD  that  decides 
the  structure  of  a  construction  document  is  crucial  for  the  degree  of 
malleability  of  a  document. 
.    Information  Integration.  The  integration  of  document  information  and  local 
information  is  achieved  by  sharing  a  common  information  index  system,  such 
as  the  CSI  Masterformat.  Although  this  research  does  not  actually  retrieve 
information  from  a  database,  based  on  the  CSI  five-digit  system  the 
Kaleidoscope  can  efficiently  and  effectively  integrate  related  information 
from  a  document  and  a  local  source.  Therefore  it  can  be  concluded  that 
current  construction  information  classification  systems  such  as  the  CSI 
Masterformat  can  be  used  as  a  neural  information  index  system. 
•    User  Interaction.  User  interactions  are  an  important  part  of  malleability.  One 
of  the  major  things  to  show  malleability  is  that  a  user  can  manipulate 
document  information  and  related  local  information  according  his/her  needs. 
This  is  achieved  by  providing  users  with  a  mixed  index  that  can  access  to  all 
related  local  information.  Besides  the  mixed  index,  Kaleidoscope  also 
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provides  a  single  index  that  allows  users  to  access  to  one  type  of  information  a 
time  and  a  document  index  that  allows  users  to  tailor  the  presentation  of  a 
particular  type  of  document.  Technically,  these  indexes  are  enough  for  uses  to 
manipulate  information. 

1.2  Hypothesis  Testing 

The  purpose  of  the  hypothesis  testing  is  to  investigate  the  superiority  of  a 
"malleable  frame"  system  to  a  standard  system.  This  objective  is  achieved  by  comparing 
two  systems,  one  with  malleability  and  the  other  without.  Participants  in  the  tests  were 
also  asked  to  answer  questions  about  their  level  of  satisfaction  with  the  two  systems  as 
well. 

At  a  level  of  significance  of  0.05  (or  95%  confidence  level),  the  original 
hypothesis  was  rejected  by  two  test  cases  (Pair  One  and  Pair  Three)  and  was  accepted  by 
one  case  (Pair  Two).  In  addition,  the  hypothesis  was  also  rejected  by  the  normalized  data 
at  a  level  of  significance  of  0.1  (or  90%  confidence  level).  Further  analysis  indicated  that 
in  some  situations  when  the  user's  local  systems  did  not  have  the  information  required 
for  processing  a  document,  or  that  the  document  processing  did  not  require  any  local 
information,  there  was  no  significant  difference  between  the  two  systems.  This  means 
that  in  those  situations,  the  system  with  malleability  is  not  actually  very  helpful  in  terms 
of  time.  However,  statistical  analysis  in  the  previous  chapter  also  indicated  that  people 
using  a  system  with  malleability  would  be  significantly  faster  than  those  using  a  system 
without  malleability  when  processing  construction  documents  if  the  required  local 
information  is  available.  Overall,  it  is  still  inconclusive  as  to  whether  the  "malleable 
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frame"  system  is  better  than  the  standard  system.  Further  data  are  required  to  make 
conclusive  decisions. 

The  sample  size  used  in  this  research  is  acceptable  at  a  level  of  significance  of 
0.05  with  a  maximum  error  of  10  seconds. 

7.3  User  Satisfaction 

With  respect  to  user  satisfaction,  most  people  (96%  in  Case  3  and  94%  in  Case  4, 
see  Figure  6.5)  reported  that  the  "malleable  frame"  system  was  helpful  by  putting  a 
Request  for  Change  Order  Proposal  together  with  related  local  information  in  the  same 
screen.  In  contrast,  only  61%  of  the  participants  (See  Figure  6.6)  reported  that  they 
needed  more  control  over  the  display  of  the  information.  This  type  of  pattern  was  also 
observed  in  each  group  with  different  levels  of  knowledge,  i.e.  school  experience,  1  to  5 
years  of  experience  and  5  or  more  years  of  experience  (See  section  6.6.4). 

In  addition,  results  showed  that  persons  with  more  work  experience  found  the 
"malleable  frame"  system  to  be  more  helpful  and  they  also  desired  more  controls  over 
the  "malleable  frame"  system  and  the  information  it  presented  (See  section  6.6.5). 


CHAPTER  8 

RECOMMENDATIONS  FOR  FURTHER  STUDIES 

Integration  of  different  data  sets  by  using  a  neutral  document  format  and  a 
standard  construction  information  index  system  is  the  goal  of  this  research.  Due  to  the 
large  scope  of  such  a  goal,  this  particular  research  focused  on  part  of  this  large  picture  by 
investigating  the  technical  feasibility  of  implementation  and  the  advantages  of  a  system 
with  malleability.  Consequently,  there  are  certain  limitations  to  this  research.  During  the 
development  of  this  research  some  new  ideas  were  generated  and  needed  to  be 
investigated.  All  these  will  be  discussed  below.  The  discussion  will  be  grouped  into  three 
categories,  topics  on  the  neutral  document  format,  topics  on  system  design  and  topics  on 
system  testing. 

8.1  Topics  on  the  Neural  Document  Format 

8.1.1  Document  Analvsis 

One  of  the  most  important  steps  in  developing  a  neutral  document  format  is  to 
identify  elements  that  need  to  be  included  and  tagged.  This  step  also  affects  the  final  data 
granularity  of  a  document  and  thus  the  access  level.  Consequently,  the  data  granularity 
and  the  access  level  will  affect  the  degree  of  malleability. 

For  this  research,  document  elements  are  generalized  from  a  set  of  documents  of 
the  same  type,  namely  a  CSI  document  and  a  customized  document,  a  Request  for 
Change  Order  Proposal.  This  approach  might  not  be  enough,  because  those  document 
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formats  are  designed  for  human  use  not  for  a  machine  to  present  its  malleability.  This 
raises  the  question  about  how  such  a  method  eventually  will  limit  a  system's 
malleability. 

Thus  it  is  suggested  here  that  it  may  be  better  for  further  studies  to  take  a  bottom 
up  approach  developing  a  comprehensive  document  object  model  based  on  available 
models  such  as  the  IFC  (Industrial  Foundation  Classes)  data  model  or  by  using  case 
scenarios.  Consequently,  objects  in  a  document  will  be  more  semantically  rich. 
8.1.2  Construction  Markup  Language 

DTDs  or  XML  schemas  define  the  vocabulary  set  (tags)  and  document  structures 
for  a  particular  application  domain.  Although  this  research  only  presents  a  method  to 
develop  a  DTD  for  a  Request  for  Change  Order  Proposal,  which  can  be  regarded  as  a 
subset  of  a  construction  markup  language,  the  significance  of  having  such  a  construction 
markup  language  becomes  very  obvious.  A  construction  markup  language  defines  the 
entire  document  set  in  terms  of  the  document  structure  and  the  vocabulary  set  for  the 
construction  industry.  With  such  a  standardized  language,  construction  information 
systems  can  achieve  data  interoperability  through  a  Web  based  "front-end"  integration 
strategy,  which  is  more  flexible. 

As  of  this  writing,  a  few  companies  such  as  the  Bentley  System  and  Timberline 
Software  are  starting  such  efforts  under  the  umbrella  of  Microsoft's  BizTalk  framework. 
The  author  of  this  dissertation  is  currently  working  for  the  Timberline  Software 
Corporation  developing  a  large  subset  of  the  construction  markup  language  that  is  related 
to  Timberline  software  applications. 
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8.2  Topics  on  System  Design 

8.2.1  Interface 

The  user  interface  was  not  a  main  focus  of  this  study.  One  of  the  problems  with 
developing  any  other  "malleable  frame"  systems  is  the  arrangement  of  the  indexes.  It 
might  be  better  if  we  combine  all  three  indexes,  the  document  index,  the  single  index  and 
the  mixed  index  into  one  or  some  other  form  that  the  user  may  like. 

Focusing  only  on  the  mechanisms  of  a  "malleable  frame"  system,  this  research 
does  not  investigate  what  kinds  of  user  interface  features  should  be  built  into  the  system. 
Further  studies  may  need  to  work  on  this  area  too  because  this  research  has  proved  that 
technically  a  "malleable  frame"  system  is  feasible  and  more  efficient  in  some  cases. 

8.2.2  User  Needs 

User's  information  needs  are  very  complicated.  Different  users  may  need 
different  local  information  even  for  processing  the  same  construction  document.  This 
research  did  not  differentiate  between  user's  specific  information  needs  and  simply 
assumed  that  schedule  information  is  all  that  is  needed.  It  would  be  helpfial  if  the  system 
can  keep  track  of  each  user's  experience  in  dealing  with  a  particular  type  of  document  to 
identify  user's  specific  information  needs. 

8.2.3  Database 

Kaleidoscope  is  not  built  upon  any  database  systems.  It  is  assumed  in  this 
research  that  local  information  that  in  most  cases  is  stored  in  a  relational  database  can  be 
exported  from  the  database  and  converted  into  XML  format.  Theoretically  it  is  feasible. 
However,  technically  this  relies  on  database  vendors'  efforts  to  incorporate  XML 
technology  into  their  database  systems. 
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Essentially,  a  "malleable  frame"  system  needs  to  be  built  around  some  type  of 
database  system.  Therefore,  it  would  be  a  great  step  forward  if  further  studies  can 
investigate  whether  a  neutral  (shared)  information  index  system  based  on  CSI 
(Construction  Specification  Institute)  Masterformat  is  technically  feasible  for  the  purpose 
of  integrating  local  information. 

8.3  Topics  on  System  Testing 

8.3.1  Testing 

In  order  to  obtain  a  pair-wise  comparison,  this  research  uses  pairs  with  two  cases. 
No  matter  how  similar  one  prepares  the  two  cases,  some  difference  will  exist.  It  is  hard  to 
predict  and  evaluate  how  the  differences  between  the  two  cases  will  affect  the  test 
variable.  So  it  would  be  interesting  to  take  another  approach.  The  new  approach  will  use 
the  same  case  for  the  two  test  systems.  The  test  process  will  be  first  let  users  do  tests  on 
either  the  standard  system  or  the  "malleable  frame"  system.  After  a  certain  period  of  time 
such  as  several  months,  let  the  users  do  the  same  case  but  on  the  other  system.  The 
assumption  of  this  approach  is  that  after  a  certain  period  of  time  the  users  will  not 
remember  the  details  of  the  tests  they  completed  earlier  so  that  the  second  test  will  not  be 
biased.  Of  course,  the  difficulties  lie  in  using  the  same  sample  in  the  second  test  and 
determining  the  time  period  to  make  the  assumption  reasonable. 

8.3.2  Testing  More  Features  Quantitatively 

This  research  only  collects  data  for  time  and  user  satisfaction.  It  would  be  very 
interesting  if  data  on  users'  behavior  can  be  collected.  Examples  include  what 
information  is  selected  as  a  default  view  for  different  users  to  deal  with  a  same  type  of 
documents,  how  many  times  a  user  needs  to  change  a  default  view  to  find  a  answer,  and 
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what  kind  of  indexes  is  the  most  used,  etc.  This  will  be  helpful  in  understanding  the 

user's  specific  information  needs. 

8.3.3  Testing  the  Whole  Process  of  Document  Processing 

As  mentioned  earlier,  the  whole  process  of  construction  document  processing  is 
composed  of  many  steps  of  decision-making.  It  would  be  interesting  if  a  study  could  be 
conducted  to  test  the  whole  process  of  document  processing.  Such  a  test  requires  a  more 
sophisticated  test  system,  and  well-designed  and  carefully  selected  test  cases. 


APPENDIX  A 

SAMPLE  CONSTRUCTION  DOCUMENTS  AND  CSI  MASTERFORMAT 


otconstwcuon  CHANGE  ORDER 

^'^'^'^  REQUEST  (PROPOSAL) 


Project    COR  Number: 


From  (Contractor): 


To:   Dite: 


AyE  Project  Number; 


RE:   Contract  For: 


This  Change  CWcr  Request  (COR)  contains  an  itemized  quotation  for  chinges  in  the  Contract  Sum  antt'or  Tune  io  response  to  proposed 
modifications  to  the  Contract  Documents  based  on  Proposal  Request  No.  


Description  of  Proposed  Change: 


D  Attachments 


Reason  For  Change: 


,c  in  CoRWci  Si 


Docs  Proposed  Change  involve  a  change  in  cMki  Sum  or  Contract  Time?  D  Yes  (H  No 

If  Yes:  Proposed  Change  in  Contract  Sum;   

Proposed  Change  In  OntracI  Time:   


Attached  Pages:      Proposal  Worksheet  Summary: 
Proposal  Worksheet  Delail(s);_ 


Signed  by:_ 


□  Attached  is  supporting  informatiop  from:n  Subcontractor  D  Supplier  □  D 

Copies;  □  Owner      □  Consultants        □  Field  □   D  □ 


Page  1  of_  July  1994 

CSl  Form  13.6A 


Figure  A.  1  A  CSI  sample  of  change  order  request  (proposal) 
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Proposal  Request 

Flagler  Hospital  -  phase  1 


OWNER  □ 

ARCHITECT  □ 

CONTRACTOR  ■ 

FIELD  □ 

OTHER  □ 


PROJECT: 


OWNER: 


ARCHITECT: 


CONTRACTOR: 


Flagler  Hospital 
1234  NW  123  St. 
Gainesville,  FL  32456 
University  of  Florida 
Gainesville,  FL  32603 
Tel:  (352)232  6785 
Fax:  (352)232  7584 

Albert  Design 
2345  NW  345Rd. 
Gainesville,  FL  32456 
Tel:  (352)456  7891 
Fax:(352)456  5647 
Gator  Construction 
3456  SE  23St. 
Gainesville,  FL  32465 
Tel:  (352)345  6789 
Fax:(352)345  9876 


PROPOSAL  REQUEST  NO:  23 
PROJECT  NUMBER:  94345 
DATE:  1/12/98 
CONTRACT  DATE:  1/10/98 


Please  submit  an  itemized  quotation  for  changes  in  the  Contract  Sum  and/or  Time 
incidental  to  proposed  modifications  to  the  Contract  Documents  described  herein. 
All  items  listed  below  may  be  clarifications  only  without  affecting  cost  or  schedule. 


THIS  IS  NOT  A  CHANGE  ORDER  NOR  A  DIRECTION  TO  PROCEED  WITH 

THE  WORK  DESCRIBED  HEREIN.  

DESCRIPTION: 


CHILLED  WATER  FOR  PHASE  II 


Provide  chilled  water  capped  in  the  ceiling  on  the  third  floor  of  the  new  patient  tower 
connector  as  request  by  the  GRGV's  PR#M09. 

Signature: 

Issued  by    xxx   Date  :  4/12/98  


Figure  A.2  A  customized  sample  of  request  for  change  order  proposal 
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CHANGE 
ORDER 

AIA  DOCUUeNT  G701 


OWNER 

ARCHITECT 
CONTRACrOK 
FIELD 
OTHER 


□ 
J 


J 


PROJECT  Palmetto  Shopping  Center 
[nanw  addrnf..  4400  W.  Absent  Ave. 

Gainesvillo.  FL  32601 

TO  CONTRACTOR:  LL  Construction  Company 
(iwmlmc'cui  123  University  Ave. 

Gainesville.  FL  32601 


CHANGE  ORDER  NUMBER:  #1 
DATE  Oct  5.  1999 
ARCHITECT'S  PROJECT  NO  1234 
CONTRACT  DATE  September  1,  1999 
CONTRACT  FOR 


The  Contract  is  changed  as  follows: 

1.  To  add  5  concrete  equipment  pads  for  A/C  units 


PLEASE  SEE  ATTACHED  DOCUMENTATION 


Not  valid  until  signed  by  the  Owner.  Architect  and  Contractor. 


The  cxigina  (ContracI  Sum)  was  

Net  clangr  hy  [^fF-viousfy  authon/ed  Change  Ontert ...   

The  (Contract  Sum)  p'toi  lo  this  Change  Orde'  waj   

The  (Coniract  Sum))      he  (increased)  t>y  Ihie  Change  Older  in  the  amount  of  .. 

The  re*  I  Contract  Sum)  mcluotng  INj  C»iar»ge  Older  wtt  be  

The  Cor1r:K:l  Time  Mill  tie  (increased)  tr/  «ve       (7)  day*. 

The  date  ot  Substantial  Comolellon  as  of  the  date  ot  this  Change  Order  therefore  is 
substantial  completion. 


S  200.209 

I  0.00 

i  200.209 

i  1.7S2 

I  201.991 


(7)  days  t>eyond  the  original  dote  ol 


NOTE   Tt*a  auwDery  does  not  reltct  changes  -n  Itw  Ccnvsct  S«m  C««^tr;ici  Timu  «*  Guitiiinlee^]  WaxUTi  i'nce  whlcn  have  been  aulncfizec 
ay  Consmiaion  Changs  OnOxyt 


ceEAiiytQe5ifiN.*tc 

ARCHITECT 

aMtt'"  STREET  SORTHS 
ADDRESS 


LL  CONSTRUCTIOK  COMPANY 
CONTRACTOR 

123  JWVERSJTV  AVE   

ADORESS 

GAINESVILLE  Fi  32601   


BHC'VW  OKOtjr  _ 

OWNER 

3201  SW  3S'F>LAC£ 


AOORESS 
GAIN6SVIL1£  FL32S«7 


Ds>»  OCTOBERS.  1989 


Date  aCIS3BEEJ.1222_ 


AIA 


Dais  OCTOBER  5.  1999 


CAUTION:  You  should  sign  an  ohginal  AIA  document  which  has  ris  caLtion  prnteo  n  blacK 

An  or-ginal  assures  that  changM  wNI  not  be  obscured  as  may  occur  when  doc  jmenis  are  reproduced. 


AIA  DOCUlaENT  G'01  -CKANGE  ORDER  •  1567  EDITION  •  AIA  •  !9S7  •  THE  AMERICAN  iNSTITUTE  OF  ARCHITECTS 
irsSNEWVORK  AVE.  MW  .  WASHINGTON.  DC  20006  G'O'-ISeT 

WARNING:  Jnaceneea  pnotococrying  violalM  U  S.  copyright  lawn  and  s  sunfsd  to  i»gai  p«us«tMiicn 


G701-1987 


Figure  A.3  A  AIA  sample  of  change  order 


APPENDIX  B 
SCREEN  SHOTS  OF  KALEIDOSCOPE 


^Applet  Viewei:  indexApp  class 

Applet  '^RMHIPf 

KALEIDOSCOPE  System 

Request  for  Change  Order  Proposal 

Flagier  Hospital 

1234  NW  123  St.,  Gainesville,  FL  32456 

Project  Number:  94345 

Proposal  Request  NO:  i  23        Proposal  Date:  1/f  2/93             Contract  Date:  1/1 0/98 

Owner: 

University  of  Florida 

Architect: 

Albert  Design 

Contractor: 

Gator  Construction 

1 

This  is  a  sample  test. 

DESCRIPTION 

CHILLED  WATER  FOR  PHASE  II 

Provide  chilled  water  capped  in  the  ceiling  on  the  third  floor  of  the  new  patient  tower  connector  as  requested 

by  the  GRGV's  PR#M09. 

Signature 

xxx                     Signature  Date  4/12/98 

Document  1  Document  Index  |  Single  Index  |  Mixed  Index  |  DefaultViews  |  Process  |  Document  Builder  | 

Applet  started. 

Figure  B.  1  An  original  document  mode 
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^Applet  Viewei;  indexApp  c 


Applet 


KALEIDOSCOPE  System 
Request  for  Change  Order  Proposal 


DESCRIPTION 

CHILLED  WATER  FOR  PHASE  II 

Provide  chilled  water  capped  In  the  cellina  on  the  third  floor  of  the  new  patient  tower  connector  as  requested 
bythe  GRGV's  PR#M09.  IMSBSBSBSSKKKttSttl^.  -Inlxl 

General  information 


P"  Document  Title  f"  Proposal  ID  ["  Proposal  Date 
n  Signature  f  Signature  Date     l~  Contract  Date 

r"  Instruction 
Project  Information 

|~  Project  f  Participant  List 

Document  Content 
F  Work  Item 


Show|  Reset]  Set  Default 

Document  1  Document  Index 

Single  Index 

Mixed  Index 

Default  Views 

Process 

Doc 

ument  Builder  { 

Applet  started. 


Figure  B.2  A  document  index  mode 
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li^Applel  Viewei:  indexApp.class 

Applet 

KALEIDOSCOPE  System 

Request  for  Change  Order  Proposal 

CHILLED  WATER  FOR  PHASE  II 

Provide  chilled  water  capped  in  the  ceiling  on  the  third  floor  of  the  new  patient  tower  connector  as  requested 

by  the  GRGV's  PR#M09. 

SCHEDULE 

Early  Start   

I                  CHILLED  WATER  FOR  PHASE  II 

budget 

It  CostAs  Design    C  Cost  Up  To  Date  C  Work  As  Design 

Ischedule 

Early  Start         C  Late  Start          C  Early  Finish 

'C  Late  Finish 

^"  1 

:                                 Show  1 

Document  1  Document  Index  |  [Single  indexjl  Mixed  Index  |  Default  Views  |  Process 

Document  Builder  | 

Applet  started 

Figure  B.3  A  local  information  index  mode 
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  MBl 

Applet 


Applet  Viewer:  indexApp.  class 


KALEIDOSCOPE  System 
Request  for  Change  Order  Proposal 


CHILLED  WATER  FOR  PHASE  II 

Provide  chilled  water  capped  In  the  celling  on  the  third  floor  of  the  new  patient  tower  connector  as  requested 
by  the  GRGV's  PR#M09. 

BUDGET  ~ 
Cost  As  Design  Cost  Up  To  Date 

$1234.56  $1000.34 


Work  As  Design 

30% 


SCHEDULE 

Early  Start 

10-3-98 


IS 


I  Local  Information  Mixed  Index 


CHILLED  WATER  FOR  PHASE  I 


budget 

p"  Cost  As  Design  p"  Cost  Up  To  Date  p"  Work  As  Design 
schedule 

F  Early  Start         f"  Late  Start  l~  Early  Finish 

r  Late  Finish 

[Shgwjl  Reset  |  Set  Default  | 


Document  | 

Document  Index  | 

Single  Index 

i  Mixed  index  j| 

Default  Views  | 

Process  | 

Document  Builder 

Applet  started. 


Figure  B.4  A  local  information  mixed  index  mode 


158 


Applet  Viewer  indexApp.clast 


Applet 


ME 


Project  Number  94345 

Owner: 

Architect: 

Contractor: 


KALEIDOSCOPE  System 


Request  for  Change  Order  Proposal 

Flagler  Hospital 
1234  NW  123  St.,  Gainesville,  FL  32456 


Proposal  Request  NO  123 

University  of  Florida 
Albert  Design 
Gator  Construction 


Proposal  Date:  1/1  Z9d 


Contract  Date:  1/1098 


^Default  View 


DESCRIPTION 

CHILLED  WATER  FOR  PHASE  II 


This  Default  Viewer 

if*  I95!2ia?l&°?'y^^^  Document  Index  (~  Mixed  Index 
I  Set  Default  View  [ 


Provide  chilled  water  capped  in  the  ceiling  on  ttie  third  floor  of  the  new  patient  tower  connector  as  requested 
by  the  GRGV's  PR#M09. 


Signature 


>oo< 


Signature  Date 


4/12/98 


Document  |  Document  Index  |  Single  Index  |  Mixed  Index   [  Default  Views j   Process  |  Document  Builder 


Applet  started 


Figure  B.5  A  default  view  setting  mode 
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Applet  Viewer:  indexApp. class 


Applet 


KALEIDOSCOPE  System 


Request  for  Change  Order  Proposal 

Flagler  Hospital 
1234  NW  123  St..  Gainesville,  FL  32456 


Project  Number  94345 

Owner: 

Architect: 

Contractor: 


Proposal  Request  NO:  1 23        Proposal  Date:  i/i  2/98 


Contract  Date:  1/1093 


University  of  Flonda 
Albert  Design 
Gator  Construction 

Process 

This  is  a  sample  test.      ^  ^^i^M^     r  Return  Report 


DESCRIPTION 

CHILLED  WATER  FOR  PHASE  II 

Provide  cnilled  water  capped  In  the  ceiling  on  the  third  floor  of  the  new  patient  tower  connector  as  requested 
Pythe  GRGV's  PR#M09. 


Signature 


XXX 


Signature  Date 


4/12/98 


Document  |  Document  Index  |  Single  Index  |  Mixed  Index  |  Default  Views  |  Process  |  Document  Builder  [ 


'Applet  started 


Figure  B.6  A  process  mode 


APPENDIX  C 
THE  TEST  SYSTEM 


Major  Screen  Shots 


Following  are  a  series  of  screen  shots  of  the  test  system. 


3  Tcsis  foi  Malleable  Fiame  Sytlemt  -  MiciotoH  Inleinet  Exploiei 


£Je    Ed»    J^iew    fio  Favaite* 

O    ^  t2s 


wmB 


Stop      Refiesh  Home 


I  Addiess  |«J  CAPThesisMesWestMndex  hlml 


®  a  0      I  a  ^  4 

Seeich    Favofiles    Hislocy    Channels  '  Fullscieen     Mai  Pi 


Main  Index    Qii-Line  Tcsting  for  Malleable  Frame  ^ 

Systems  " 


Home 


Start 


*J  Done 


Objective  of  the  Testing 

You  will  be  given  two  t5rpes  of  tests.  In  type  one  tests,  a  request  for  change  order  proposal  and 
project  schedule  information  are  shown  in  separate  windows.  In  type  two  tests,  a  request  for 
change  order  proposal  and  project  schedule  information  are  shown  in  the  same  window.  You 
are  asked  to  make  a  decision  on  whether  there  is  any  extra  cost  incurred  by  the  change  stated 
in  the  request  for  change  order  proposal  The  objective  is  to  find  out  which  type  is  more 
convenient  for  you  to  make  such  a  decision.  This  is  done  by  associating  each  case  with  a  timer 
to  record  how  long  it  takes  to  make  a  decision. 


A. 


'gigjfcf  IJlMyCompulei 


Figure  C.l  General  introduction  screen 


3  Tests  lor  Malleable  Fi. 


J  Systems  -  Miciosott  Internet  I  xplmer 


file    £*    ^iew    Qo    FavtxHos  Uolp 

j      Back  Stop  Refresh 

]  Address  |0J  CAPThesisMestMeslSindex  html 


4 

Horne 

Search 

Hi 

Favorites 

History 

Channels 

Fuiscieen 

Mai 

Pi 

d 

1  LMu 

1 


Index 


Home 


Sample  1 


Sample  2 


Cost  I 


Results  I 
gJDone 


4 


Instructions  to  the  Tests 


Content 


Instruction  j 
Schedule  | 


•  Index  Bar  Buttons 

•  Proiect  InfoiTnation  Window 

•  Tegting  Process 

•  Requirements 

•  Explanations  to  Sample  Tests 


Index  Bar  Buttons 

The  index  bar  on  the  left  side  contains  several  buttons  that  are  important  for  conducting  tests. 


.5 


1.    "Home"  IS  leading  back  to  the  general  information  page 

2  "Instruction"  is  leading  to  this  page 

3  "Schedule"  is  for  open  a  new  window  showing  related  project  schedule  information.  The 
system  will  take  care  of  when  to  display  the  schedule  information-  So  normally  you  do 
not  need  it  . 

4  '5^amr^l^  1 '  anH  ^5^aml->U  7'  arr  gamrtlp  t^<fr<  Hr<iot^pH  fnr  vr,u  tf^^o^*  familiar  with  thp 

I  r~r~l~iaMvCoirpul« 


Figure  C.2  Instructions  to  the  tests 
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□     sis  loi  Malleable  Fiame  Sytlemt  -  Miciasoft  Inleinet  Exploiei 

[nl  vl 

1  £ile    EcK    View    fio    Favofites  Help 

o 

\  ^  ,   .  ,  ©   a   t3  '  m 

!     Back                        Stop      Reltesh     Home    j    Search  Favaite* 

Histoiy 

Channels  Fullscieen 

Mail 

Pti 

Address  |0J  C  \PThesisMesWesl\index.html 

i  Unkti 

3 


Index 


Instructions  to  the  Tests 


Home 


Instrudion 


Content 

•  Index  Bar  Buttons 


Schedule 


Sample  1 


Sample  2 


Case  1 


Case  2 


Case  3 


Case  4 


•  Proiect  Informatior 

•  Testina  Process 

•  Reaiurements 

•  Explanations  to  Sa 

Miciosolt  Internet  Exploiei       Q 1 

vou  leady  for  the  tests? 
%   |j      Qi;--  j|      Cancel  | 

Cost 


No  Cost 


Index  Bar  Buttons 

The  index  bar  on  the  left  side  contains  several  buttons  that  are  important  for  conducting  tests. 

1 .  "Home"  is  leading  back  to  the  general  information  page. 

2.  "Instruction'  is  leading  to  this  page. 

3.  "Schedule"  is  for  open  a  new  window  showing  related  project  schedule  information.  The 


"  i     I     I  My  Computet 


Figure  C.3  A  dialogue  box  controlling  the  start  of  tests 


^  Piojecl  was  -  lest  -  Miciosoll  Internet  Exploiei 

]  Be   £dt   yiew   fio    Fjvorilet  Help 

1 

fmiri        Slop  Refresh 

^  ! 

Home 

'21        L*J        ^  ^ 
Search    Favorites    History  Channels 

3 

Fullscreen 

Mail 

P(ir 

|Addie«»  1*]  CAPThesisMestMeslSschl.htm 

JjjLrksi 

ID 

I'esirnptioii 

Duration 

1 

Start 
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Float 

1  General  Condilion 

100 

purchase  ceremic  tile 

30 
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IJanOO 
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1.3.4  First  Eoor  _ 
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0 
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0 
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0 
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Fire  retardant  paint 

5 

llFebOO 

17FebOO 
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0 

1.3.4.2  Floor  ifl^^^BM^II^^^HI^H^^^Hil^HHII^I 

4310 

Concrete  slab  on  grade 

7 

31Aug99 

06Sep99 

09Sep99 

15Sep99 

10 

1 

S320 

Ceramic  mosiac  tile 

leFeb^O 

17Feb00j  17MarO0 
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i  22 

1.3.4.3  First  Floor  Ceiling  IHHIi^HI^^^HI^^^^^^HHHHB^ 

1.3.4.4 FirstFloor Doors  andV/mdows  'S^^^^^^^^^^H^^^^^H^^^IE' 

The  new  door  D  - 1 0 1 C  has  not  deSned, 

/5 

1 

rrr 

]^  MyComputei 

Figure  C.4  Related  schedule  information 
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1  3  TesU  loi  Malleable  Fiaroe  Sysleros   Mictosoll  Inleinet  Eiiplmei 
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^     ,       ->     ,  © 
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Histoiy 
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Pi 
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Index 


Home 


Instruction 


Schedule 


Sample  1 


Sample  2 


Case  1 


Case  2 


Case  3 


Case  4 


Cost 


No  Cost 


IgJDone 


Case  1 

Request  for  Change  Order  Proposal 

Gator  Academic  Advisement  Center  -  Phase  1 


Microsoft  Internet  Exploiei 


The  schedule  infoimation  window  is  minized  on  your  window's  task  bar.  A  clock  will  start 
liming  i(  click  on  "OK",  so  don't  click  until  pages  ate  completely  loadedll  Also  it  is  assumed 
that  the  date  of  today  is  what  is  shown  in  the  document  as  "Date"  in  red.  Please  decide  il    |;t  Date: 
there  is  extra  cost  associated  with  this  change.  Dick  "cost"  loi  extra  cost  or  "no  cost"  ior 
no  extra  cost 


] 


1)K" 


Cancel 


;identid  to 
below 


may  be  clarifications  only  without  affecting  cost  or  schedule, 

THIS  IS  NOT  A  CHANGE  ORDER  NOR  A  DIRECTION  TO  PROCEED  WITH 
THE  WORK  DESCRIBED  THEREIN. 


DESCRIPTION: 


a  My  Con\putei 


Figure  C.5  A  dialogue  box  controlling  the  start  of  timing 


3  Tests  loi  Malleable  Fiame  Systems  -  Miciotolt  Internet  Eiiploiei 
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02 


Case  1 

Request  for  Change  Order  Proposal 

Gator  Academic  Advisement  Center  -  Phase  1 


Miciosolt  Internet  Exploiei 


Please  write  down  the  tollwoing  information.  Start  Time;  20:30:32  End  Time:  20:30:3S 
Selection:  Cost 


act  Date: 


ncidental  to 


Pli  

proposed  modifications  to  the  Contract  Documents  described  herein  All  items  listed  below 
may  be  clarifications  only  without  affecting  cost  or  schedule. 

THIS  IS  NOT  A  CHANGE  ORDER  NOR  A  DIRECTION  TO  PROCEED  WITH 
THE  WORK  DESCRIBED  THEREIN. 

DESCRIPTION: 


T^MyCon^utw 


Figure  C.6  A  dialogue  box  showing  a  test  result 
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Pr 
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Jlinks 

Index  Survey 


Home  I 


Please  complete  this  survey  and  don't  click  on  any  buttons  on  the  index  bar.  Click 
button  "Go  on"  below  on  this  page  to  continue. 


Instruction  | 


Schedule 


Sample  1 


Sample  2 


Cose  1 


Case  2 


Case  3 


Case  4 


Cost 


No  Cost 


1)  Do  you  End  it  helpful  for  this  case  (case  3)  by  putting  the  request  for  change  order 
proposal  and  related  project  information  on  the  same  page  when  dealing  with  change 
orders? 

<~  Extremely  helpful 
r  Very  helpful 
r  Helpful 
C  Not  very  helpful 
<~  Not  helpful  at  all 

2)  For  this  case  (case  3),  do  you  wish  to  have  control  over  how  the  request  for  change 
order  proposal  and  the  related  project  information  are  presented  to  you  if  they  are  on 
the  same  page? 

r  Yes 

C  Not  sure 


■gljone 


"|^MyCo»nputei 


Figure  C.7  Survey  to  assess  user  satisfaction  with  the  "malleable  frame"  system 
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Test  Results  (Final) 

Please  follow  the  instructions  shown  at  the  bottom  of  this  page  to  submit  your  results 
Case  1: 

Start  Time:  20  30  32;  End  Time:  20:30  36;  Selection:  Cost 
Case  2: 

Start  Time:  20  31:46;  End  Time:  20  31:48,  Selection:  Cost 
Case  3: 

Start  Time:  20  31:54.  End  Time:  20  31  56,  Selection:  No  Cost 
Case  4: 

Start  Time:  20:32:54;  End  Time:  20:32:56,  Selection:  Cost 


Your  experience  about  dealing  with  change  order  is:  Familiar 

Your  answer  to  the  question  "Do  you  find  it  helpful  by  putting  the  request  for  change  order 
proposal  and  related  project  information  on  the  same  page  when  dealing  with  change  orders?"  is: 

HelpfiJ(case  3)  Helpflil(case4) 

Your  answer  to  the  question  "As  a  end-user,  do  you  wish  to  have  control  over  how  the  request  for 
change  order  proposal  and  the  related  project  information  are  presented  to  you  if  they  are  on  the 
same  paee?"  is:  Not  surefcase  31  Not  surefcase  4)  ^ 


i  ^  My  Computer 


Figure  C.8  Sample  screen  of  final  results 
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Scenario 

The  construction  project  for  the  tests  is  a  three-story  building  called  Gator 
Academic  Advisement  Center.  The  floor  plan  of  the  first  floor  is  shown  below.  There  are 
two  types  of  tests  that  will  focus  on  changes  affecting  one  room,  Room  101.  The 
drawing,  Figure  C.9,  shows  the  floor  plan  and  where  Room  101  is  located. 

 -a 

— =1  ..  I  [ 


A. 


-up- 


-up- 


101 


101 


Figure  C.9  The  floor  plan 
Figure  C.IO  shows  some  detailed  information  about  Room  101. 
Request  for  Change  Order  Proposals  will  be  given  regarding  changes  to  Room 

101.  What  testers  need  to  do,  is  to  decide  whether  there  is  any  extra  cost  incurred  due  to 

the  proposed  changes. 

Certain  assumptions  are  made  in  order  to  complete  the  tests.  These  assumptions 

are  as  follows: 


1.  Only  schedule  information  affects  cost  changes. 
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2.  The  date  on  the  Request  for  Change  Order  Proposal  is  the  date  of  today. 

3.  All  partition  walls  related  to  this  room  are  referred  to  as  "First  Floor  Interior  Wall"  in 
the  project  schedule  (Figure  C.IO). 

4.  All  exterior  walls  related  to  this  room  are  referred  to  as  "First  Floor  Exterior  Wall"  in 
the  project  schedule  (Figure  C.IO). 

5.  For  the  test  purpose,  project  schedule  only  includes  activities  that  are  related  to 
changes. 

6.  Room  101  is  on  the  first  floor. 


Exterior  Wall 


Figure  C.IO  Room  101 
Flow  Control 

It  is  important  that  each  user  follows  the  same  flow  of  steps  during  testing.  To 
achieve  this  objective  a  handful  of  user  interface  features  such  dialogue  boxes  and 
prompts  are  used.  Figure  C.  1 1  shows  the  designed  flow  of  test  steps. 


Figure  C.  1 1  Flowchart  of  test  steps 
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Schedule 

The  scheduling  of  related  activities  for  Case  One  and  Case  Two  is  in  Table  C.l. 


Table  C.l  Schedule  of  related  activities  for  Case  One  and  Case  Two 


Act.  ID 

Description 

Duration 

Early 
Start 

Early 
Finish 

Late 
Start 

Late 
Finish 

Total 
Float 

1  Gener 

i\  Condition 

100  1 

purchase  ceramic  tile 

30 

lAug99  30Aug99 

IJanOO  1 

30JanOO  | 

134 

1.3.4  First  Floor 

1.3.4.1  First  Floor  Interior  Wall 

4130 

Set  steel  stud  partition 

12 

04Jan00 

19Jan00 

04Jan00 

19Jan00 

0 

4160 

Hang  fire  rated  gypsum  board 

8 

20Jan00 

31JanOO 

20JanOO 

31Jan00 

0 

4170 

Tape,  spackle,  and  sand  gypsum  board 

8 

OlFebOO 

lOFebOO 

OlFebOO 

lOFebOO 

0 

4190 

Fire  retardant  paint 

5 

llFebOO 

17FebOO 

llFebOO 

HFebOO 

0 

1.3.4.2  1 

^loor 

4310 

Concrete  slab  on  grade 

7 

31Aug99 

06Sep99 

09Sep99 

15Sep99 

10 

4320 

Ceramic  mosaic  tile 

2 

16Feb00 

17Feb00 

17MarOO 

20MarOO 

22 

1.3.4.31 

^irst  Floor  Ceiling 

1.3.4.4  First  Floor  Doors  and  Windows 

The  new  door  D- 101 C  has  not  defined. 

1.3.4.5  First  Floor  Plumbing 

1.3.4.6  First  Floor  HVAC 

4800 

Rough  in  HVAC 

2 

20Jan00 

21Jan00 

03FebOO 

04Feb00 

10 

4810 

Inspect  rough  in  HVAC 

1 

24Jan00 

24Jan00 

07Feb00 

07FebOO 

10 

4820 

Install  thermostat 

2 

25JanOO 

26Jan00 

17Mar00 

18MarOO 

38 

4830 

Install  grilles 

1 

26Jan00 

26Jan00 

08Feb00 

lOFebOO 

10 

4840 

Install  HVAC  unit  including  A/C  units 

3 

25Jan00 

27JanOO 

17MarOO 

19MarOO 

39 

4850 

Connect  HVAC  units  including  A/C 
units 

1 

28Jan00 

28JanOO 

20MarOO 

20MarOO 

38 

4860 

Test  HVAC  unit 

1 

29JanOO 

29Jan00 

21MarOO 

21Mar00 

39 

1.3.4.7 

-irst  Floor  Electrical 

1.3. 10  Exterior  Wall 

7800 

Erect  concrete  unit  masonry 

25 

270ct99 

30Nov99 

270ct99 

30Nov99 

0 

7810 

Bituminous  damp-proofing 

8 

15Dec99 

24Dec99 

20Dec99 

29Dec99 

3 

7820 

Hang  rigid  insulation 

8 

27Dec99 

05JanOO 

30Dec99 

lOJanOO 

3 

7830 

Place  brick  unit  face  masonry 

20 

06Jan00 

02Feb00 

llJanOO 

07FebOO 

3 

7840 

Set  precast  concrete  panel 

8 

03Feb00 

14Feb00 

OSFebOO 

HFebOO 

3 

7850 

Clean 

7 

15FebOO 

23Feb00 

18FebOO 

28FebOO 

3 

7860 

Set  metal  furring  chaimel 

10 

01Dec99 

14Dec99 

06Dec99 

17Dec99 

3 

7870 

Set  precast  sill 

8 

03FebOO 

HFebOO 

OSFebOO 

HFebOO 

3 
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Test  Cases 

Four  different  cases  are  used  in  the  tests,  two  for  the  standard  system  and  two  for 
the  "malleable  frame"  system. 
Test  Case  One 

Test  Case  One  involves  changing  the  position  of  the  A/C  unit  in  Room  101  (refer 
to  Figure  C.12).  The  height  of  the  position  and  other  conditions  remain  the  same.  In  order 
to  use  the  included  project  schedule  (Table  C.  1),  the  issue  date  of  the  Request  for  Change 
Order  Proposal  is  assumed  to  be  March  1 ,  2000. 


Interior  Wall 


Figure  C.  12  Revision  to  the  A/C  unit  in  Room  101 
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Test  Case  Two 


Test  Case  Two  involves  adding  a  new  door  to  Room  101  (refer  to  Figure  C.13 


and  Figure  C.14). 


Interior  Wall 


W-IOIA 


W-IOIB 


I 


Exterior  Wall 


Figure  C.13  Original  plan 


Exterior  Wall 

ttllliiaiililMyMltgditta*liin  uniiiMni  II -  ■■.T>«iir-iiiifw«riirf 

Figure  C.14  Revised  Plan 
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Test  Case  Three 

Test  Case  Three  involves  changing  the  light  switch  location  in  Room  101  (refer  to 
Figure  C.15). 


Exterior  Wall 

.^OMIIilittiiMHMiliM^ 


Figure  C.15  Light  switch  location  change 
Since  test  case  three  is  for  the  "malleable  frame"  system,  the  schedule 
information  shown  in  Table  C.l  is  placed  in  the  same  with  the  document  itself. 
Test  Case  Four 

Test  case  four  is  for  adding  a  new  window  to  room  101.  Figure  C.16  shows  the 
location  of  the  new  window,  W-IOIC. 

Similarly,  since  test  case  four  is  for  the  "malleable  frame"  system  as  well  the 
schedule  information  (Table  C.2)  is  shown  in  the  same  window  with  the  document. 
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Table  C.l  Schedule  information  regarding  light  switch  in  Case  Three 


Act. 
ID 

Description 

Duration 

Early  Start 

Early  Finish 

Late  Start 

Late  Finish 

Total 
Float 

1.3.4.7  I 

Mrst  Floor  Electric 

4900 

Rough  in  electrical 

3 

20Jan00 

24Jan00 

28Feb00 

OlMarOO 

27 

4910 

Inspect  rough  in  electrical 

I 

25JanOO 

25JanOO 

lOMarOO 

lOMarOO 

33 

4920 

Pull  wire 

3 

26Jan00 

28Jan00 

13MarO0 

ISMarOO 

33 

4930 

Install  connect  panel 

2 

3IJan00 

OIFebOO 

17MarOO 

20Mar00 

34 

4940 

Install  light  fixtures 

3 

3IJanOO 

02FebOO 

16Mar00 

20MarO0 

33 

4950 

Install  electrical  appliances 

1 

31JanOO 

31JanOO 

20MarOO 

20MarOO 

35 

1 .3.4. 1  First  Floor  Interior  Wall 

4130 

Set  steel  stud  partition 

12 

04JanOO 

19Jan00 

04Jan00 

I9Jan00 

0 

4160 

Hang  fire  rated  gypsum 
board 

8 

20Jan00 

31JanOO 

20Jan00 

3IJan00 

0 

4170 

Tape,  spackle,  and  sand 
gypsum  board 

8 

OIFebOO 

lOFebOO 

OIFebOO 

lOFebOO 

0 

4190 

Fire  retardant  paint 

5 

lIFebOO 

17Feb00 

llFebOO 

I7Feb00 

0 

Table  C.2  Schedule  information  regarding  the  exterior  wall  in  Case  Four 


Act.  ID 

Description 

Duration 

Early  Start 

Early  Finish 

Late  Start 

Late  Finish 

Total 
Float 

1.3.10  Exterior  Wall 

7800 

Erect  concrete  unit  masonry 

25 

270ct99 

30Nov99 

270ct99 

30Nov99 

0 

7810 

Bituminous  damp-proofing 

8 

I5Dec99 

24Dec99 

20Dec99 

29Dec99 

3 

7820 

Hang  rigid  insulation 

8 

27Dec99 

OSJanOO 

30Dec99 

lOJanOO 

3 

7830 

Place  brick  unit  face 
masonry 

20 

06Jan00 

02Feb00 

llJanOO 

07Feb00 

3 

7840 

Set  precast  concrete  panel 

8 

03Feb00 

MFebOO 

OSFebOO 

17Feb00 

3 

7850 

Clean 

7 

ISFebOO 

23FebOO 

ISFebOO 

28Feb00 

3 

7860 

Set  metal  fiirring  channel 

10 

01Dec99 

14Dec99 

06Dec99 

l7Dec99 

3 

7870 

Set  precast  sill 

8 

03Feb00 

HFebOO 

OSFebOO 

I7Feb00 

3 

The  new  window  is  not  defined  in  the  original  schedule 
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Figure  C.16  Location  of  the  new  window 
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Survey  Form 

The  following  is  the  survey  form  used  for  collecting  test  data: 
Survey  Answer  Sheet 


Case  2 


Case  3 


Case  4 


Top  of  Form  1 

Test  time  and  selections: 
Case  1 

Start  Time: 
End  Time  : 
Selection  : 


1.  Do  you  find  it  helpful  when  the  request  for  change  order  proposal  and  related 
project  information  are  on  the  same  computer  screen  when  dealing  with  change 
orders? 

Case  3  Case  4 

r 


r 
r 
r 
r 


Extremely  helpful 
Very  helpfiil 
Helpful 

Not  very  helpful 
Not  helpful  at  all 


r 
r 
r 
r 
r 


Extremely  helpful 
Very  helpfiil 
Helpful 

Not  very  helpful 
Not  helpful  at  all 


2.  As  an  end-user,  do  you  wish  to  have  control  over  how  the  request  for  change 
order  proposal  and  the  related  project  information  are  presented  to  you,  even  when 
they  are  on  the  same  computer  screen? 
Case  3  Case  4 


r 


r 


r 


Yes 

Not  sure 
No 


r 


r 


r 


Yes 

Not  sure 
No 


3.  Your  knowledge  about  dealing  with  change  orders  is: 


r 


r 


r 


r 


r 


Excellent  (more  than  10  years  of  working  knowledge  of  change  orders) 
Very  familiar  (5-10  years  of  working  knowledge  of  change  orders) 
Familiar  (1-5  years  of  working  knowledge  of  change  orders) 
Not  familiar  (school  experience) 
Don't  know  at  all 


APPENDIX  D 
GLOSSARY 


Acronym 

Standard  Name 

Aflvnnrpfl  Pnnstnictinn  Technoloev  Svstem 

AiitnPAn  Dpvplnnmpnt  Svstem 

Amhitpptiirp  FnoitippHnp  Construction 

k^lillCv  LLll  V  ^ll^lllW^l  lllf^  v^\jiiij  i-i  t*w  1.1  wi» 

A  CC 

AccnnintpH  frPtipral  Contractors  of  America 

ATA 
AlA 

Ampripan  Institntp  of  Architect 

iL'Clll  lllolllULW  \J±  iklVllll^/Vl 

AIT 

AutoCAD  IGES  Translator 

A  MQT 

ATr»(=»rir»an  \Iatinnal  ^standards  Institute 

A  DT 

Arl 

A  CDC 

A  mf^riptin  ^nripfv  nf  Proff  SsioTial  RstimatorS 

A  TT  A  C 

A 1  LAo 

Arphitpptiirps  Mpfhoflolopies  and  Tools  for  ComDuter  Integration  Large 

DOL/ W 

Rflcif  ^iinnorted  Pollahorative  Work 

r^nct  RrpaVHowTi  Sltnirtiire 

V_^U3l  JL>  1  V dlvUVJ  W  1 1  LJ 11         11*1  V 

r^V\  ATA 
UUA  1 A 

Chqrpptpr  DATA 

i^EoiVllVl 

Civil  Fnainpprinp  Standard  Method  of  Measurement 

r^nmniitpr  Tntparatpd  Construction 

r^r^nctnir'tinn  Tnfnrmation  Classification  Svstem 

r^Onctriiftinn  ICnowlpdpp  FxHCft 

Cnmnnnpnt  OHipct  Modpl 

COMniitpr  Models  for  the  Buildine  Industrv  in  Europe 

POP 

diiiinop  Ordpr  Prnnnsal 

v^r  ivi 

Pritiral  Path  Method 

\w'llllwdl  1  dill  iVlVl.llV/\J 

per" 

Cnnstnirtion  Snecification  Canada 

V^oV^  W 

Cnmniitpr  Snnnorted  Collahorative  Work 

JJI5iVlo 

r^atahasp  Manapement  Svstem 

l^dldL/dOV  IVAdlld^Wl  11  Will-  Ljj'OlVlXl 

nT4T1VfT 

nvnamir  Hvnertext  Markun  Laneuaee 

LfyJiVL 

Oneiimpnt  Ohiert  Model 

U  1  u 

rinriiment  Tvnp  Definition 

L-ZL/CtillivllL   1  y  J_/WJ.lllltHJii 

PRMF 
CDiNr 

pYtended  Raekus-Nanr  Form 

C  J  v_.  U 

Fnoinpprs  Joint  Contract  Document  Committee 

VJoA 

Crpnpral  Sprvicp  Administration 

VJ^llWidl  OVl  V  iwv  iiUiiiimoLi  u.ii»_'ii 

H\/r\prtpvt  Dp<:icyn  M^odpl 

T-Tx/nprXpYt  M^arWiin  T  ancruapp 

lAI 

Industry  Alliance  for  Interoperability 

ILUIN 

miegrdiion  01  v^oiibLiuLiiuii  iiiiuiiiiaiioii 

IT7P 

inuusiry  ruuiiuaiiuii  v^iaas 

Tmi^-ioI  /^t-ot^Mi/^c  Fv^ViQnrT^^c  d^ppiTipatir^Ti 
iniliai  OrapniCs  CACIlallJ^ca  opCLllH^alioii 

Tnts>rtrQt(»H  k^nr\Mi/lpHop  TntpriQivp  ^vstpm  for  Construction  Safetv  and 
xnicgraicu  rvJiuwicLi&c  iiiiciioivc  oysitin  ivji  x-^uncsLiuviiwii  ijdivi.j' 

Health  Performance  Control 

ISO 

International  Organization  for  Standardization 

IT 

Information  Technology 

KBDBI 

Knowledge-Based  Database  Interface 

KBSI 

Knowledge-Based  System  Interface 
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177 


ivir  o 

Malleable  Frame  Svstem 

Mn  AlVf 

Nptwnrk  Data  Access  Manaeer 

nhiert-Oriented  Hvnertext  Develooment  Methodology 

\Jrol 

Ohiert-mnflel  based  Proiect  Information  Svstem 

OQtl  A 

Orpnnntinnal  Safetv  and  Health  Administration 

Prr»if»rt  Manaapmpnt  Information  Control  Svstem 

isX^KJr 

Rpniipct  for  CHanap  Order  Pronosal 

KJJr 

Rpcmirrp  Op<irrintion  Framework 

D  PT 

Krl 

T?^*niipct  Pr^r  Information 

K-KiVl 

Rplationtjhin  Manapement  Methodolosv 

I)Lj1V1L 

^t^nHarH  frpnpraliypd  Markiin  Lanffuaffe 

cc 

OLdllUdiU  Ojoltlll 

a  1  lir 

Standard  for  the  Fxchanffc  of  Product  Model  Data 

AYtpnHpd  \/larVnn  I  anoiiapp 

YCT 

fkYt(=»ndpd  Qfvlp  I  antrnapp 

T  Tr"T 

T  Tnifr^rm  r^nn<i;tniPtion  Indpx 

T  TT?T 
UK  1 

I  Tnpprtaintv  Rpdnrtion  Theorv 

UUCI 

United  Classification  for  the  Construction  Industry 

W3C 

World  Wide  Web  Consortium 

WBS 

Work  Breakdown  Structure 

WDDX 

Web  Distributed  Data  Exchange 

WWW 

World  Wide  Web 
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